БД больницы
задача сделать так что бы в случае попадания базы в руки злоумышленников было максимально трудно сопоставить данные накопленные в базе данных (анамнезы, истории болезней, диагнозы) реальным людям

т.е. с одной стороны у злоумышленников есть таблица физ. лиц ФИО, др, СНИЛС
с другой - истории болезней
и надо сделать так чтобы сопоставить эти две таблицы было не возможно

тогда 17

(17) а поподробнее,
её возможно подключить к 1С внешним источником
запросы к ней как строить?

(22) внешним можно. например через провайдер. а запросы никак. чем то придется жертвовать.

херней не майтесть....

делается все элементарно:

1. делается полная история которая хранится в реквизите элемента справочника (тип хранилище, в нем зашифрованый файл...)
2. делается регистр для поиска по основным критериям

при записи зашифрованого файла в регистре делаем перезапись ключевых значений.

(24) не останавливайся, продолжай, как запрос расшифрует это гамно?

(24) т.е. фио шифруем в файл и в хранилище значений
а че за регистр?

таблица пациентов нужна открытая - документы создаются по пациенту, для этого его надо найти - по фио, но в основном по др

(25) запрос - никак, ему это и нельзя по методике...

запрос использует регист строит отчет, а детализацию можно получить только нажав кнопку на против конкретной строки

(28) вот-вот. теперь смотри (22)

дата рождения это практически ключ для поиска пациентов - т.е. нельзя допустить сопоставления документа и даты рождения пациента по этому документу

(0) Купите готовое решение для клиники.

(29) да не - нормально - т.е. получение выборок с персональными требуется редко и скоростью выполнения тут можно пожертвовать

(31) я так понимаю вы такое уже используете - ссылочку кинь

(29) но список пациентов должен быть открыт - к нему постоянно идет обращение - все документы создаются по пациенту, т.е. сначала надо найти пациента в базе

(30)(29)

моя схема позволяет увидить

Иванов ИИ - Болел
             группа болезней 1 - 1, 30 января
             группа болезней 2 - нет
             группа болезней 3 - 2001 год.

без конкритизации, и кнопка "детально"              
для мед статистики - прокатит и защищена конкретика

(35) не понял реализации

(0) извните но вы фигнёй страдаете! идите на профильные форумы где обсуждается закон о персональных данных и требовния к его защите.

1. делается полная история которая хранится в реквизите элемента справочника (тип хранилище, в нем зашифрованый файл...)

что такое "полная история"?

(35) так низя. можно по закону:
группа болезней 1
  болел: Пациент 1, Пациент 7
группа болезней 2
  болел: нет
группа болезней 3
  болел: Пациент 4, Пациент 83

(38)(36) делается полная история (чем болел, что пил и т.д.) и краткая (в формате который не нарушает требование закона)

полная - лежит в зашифрованом виде и доступна только по кнопке

краткая (в моем случае эт признак группы заболивания и дата) хранится в регистре и импользуется для отчетов

RomaH, вам для чего это вообще? Для сертификации в ФСТ? Для себя или чисто потренироваться в программированнии?

(40) не - не пойдет, БД для того и делается, что бы можно было делать стат выборки по ВСЕМ данным введенным

(39) смотря в какую группу защиты попадаем....

(0) кстати закон не предусматривает защиту в случае кражы базы, закон ограничивает "неправомерное использование" то есть слив с базы а не самой базы.

(41) все и сразу, кроме сертификации
просто иногда задумываюсь, а что будет если наша база попадет наружу

(42) закон в явном виде ЗАПРЕЩАЕТ делать выборки по всем введенным данным, как это не смешно звучит, но это так...

(44) не обольщяйтесь, есл базу захотят слить - м это не поможет

(45) выборки будут не по персональным данным - ну кто-то там болел

да, может не правильно ветку назвал - пофиг на закон
вот сейчас реализую ввод данных осмотра специалистами - гинеколог, проктолог, уролог, онколог
по человечески просто не правильно если данные попадут не в те руки

(47) персональные данные - это данные по которым можно идентифицировать физ лицо, то есть в выборках не будет фамилий? тогда вариант (39)

(49) а че там было?

(48) тогда просто RLS прикрути и не парься

(51) РЛС не спасет при наличии dt

(45) не совсем так, стать 6 ФЗ:
1. Обработка персональных данных должна осуществляться с соблюдением принципов и правил, предусмотренных настоящим Федеральным законом. Обработка персональных данных допускается в следующих случаях:
........................
4) обработка персональных данных необходима для предоставления государственной или муниципальной услуги в соответствии с Федеральным законом от 27 июля 2010 года N 210-ФЗ «Об организации предоставления государственных и муниципальных услуг», для обеспечения предоставления такой услуги, для регистрации субъекта персональных данных на едином портале государственных и муниципальных услуг;
5) обработка персональных данных необходима для исполнения договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект персональных данных, а также для заключения договора по инициативе субъекта персональных данных или договора, по которому субъект персональных данных будет являться выгодоприобретателем или поручителем;

под пункт 4 попадают го. больнички, под пункт 5 - коммерческие

(52) если базу слили - то спасет только шифрование данных, а по зашифрованым данным запросы не сделаешь в принцепе.

по этому в общем случае если базу "увели" - значит она полностью открыта...

(54) а почему не поможет шифрование только ключа связи?

(54) в случае "увели базу" не факт что до кучи и не "увели пароль к базе", поэтому орг. мероприятия не менее важны!

т.е. берем УИН пациента
шифруем его и пишем в документ
для того что бы узнать чей это документ - ключ надо расшифровать и по УИН получить пациента
и наоборот - по пациенту получить документы - зашифровать УИН (вот тут всегда будем получать одинаковые данные на выходе?) и получить по полученому ключу списки документов

(56) Ты про что? Про пароли в 1С???

(0) и накой хрен все это?

опять вы пытаетесь 1Сом сделать то что делается вовсе даже НЕ 1Сом...


отсюда и все шизоидные велокаты...

сделать вк и шифровать фио ими, чего херней страдать

еще раз, это все НЕ решение и это все НЕ нужно.
никакие ВК не нужны
никакое шифрование ВНУТРИ базы не нужно.

(61)предлагаешь просто максимально закрыть доступ к базе?

(62) Действительно, проще обеспечить неворуемость базы

(62) конечно.. даже для 1го класса этого достаточно.

там 90% мер это меры в отношении окружающей базу среды - политики паролей, доступ физический в серверную, графики бекапов и прочие орг вопросы..

не ну конечно понятно, нужно соответствовать закону а раз за базу отвечает 1Сник то пусть и обеспечивает

но это все полная х.ня - достаточно почитать требования к класности, там непосредственно ВНУТРЕ базы телодвижений минимум.. которые обеспечиваются типовй ЗУПой например уже давным давно..
нужен первый класс - нашлепку докупили на сервер и все - остальное это АДМИНИСТРАТИВНЫЕ телодвижения...

(64) кстати УФ позволяют довести процесс защиты базы практически до 100% (ну ладно снизить до минимума возможность слить базу)

Нефиг любить мозги, делайте как положено: хранение НЕЗАШИФРОВАННОЙ базы на ШИФРОВАННОМ диске. Шифрование диска делается СЕРТИФИЦИРОВАННОЙ программой, например, SecretDisk с аппаратной защитой (токен).

А самопальные алгоритмы не прикроют корму при проверке. Да и в случае шифрования - где будешь хранить алгоритм и пароли? В коде? Ну-ну...

любому, даже самому недалекому 1снику должно быть понятно что с самопальными велокатами ни одна сертификационная комиссия не сертифицирует вашу "систему"

тем более что эти велокаты НЕ нужны

и вообще, грешно тупить по такому разжеванному вопросу:

http://its.1c.ru/db/stafft#content:27309:1

ладно, как оградить данные от доступа к ним программиста на поддержке?
т.е. от меня, и еще пары программистов?
как сделать так что бы я не увидел результаты гинекологического обследования сотрудницы сидящей напротив, и что бы она не увидела результаты обследования меня  проктологом?

т.е. забудем о законе, тут именно РЕАЛЬНАЯ защита данных

(70) никак.
это опять же решается АДМИНИСТРАТИВНЫМИ методами - подписки о неразглашении например либо работа не с РЕАЛЬНЫМИ базами.

(70) ктож вам кодерам то реальные базы то выдал?

пороть!

(72) работа с не реальными данными - сложновато
(73) кодеры на поддержке однако - и швец и жнец и на дуде игрец

и как без доступа к реальным данным решать вопросы типа: вот из регистратуры звонят, тут по документу № ... от даты ... не печатает номер полиса - почему, или почему полис не нашло в базе ОМС?

(74) а соответствие ФЗ да еще и по первому классу само по себе  "сложновато"

(74) да да.. программист лезет а в базе "шифрованый мусор" и он не понимает - непечатает потому что там нет даты или она неправильная/неформатная или непечатает потому что еще что..


точно..
или лезет а там все хорошо и программист не знает - не в модуле шифрования ли косяк..

ага

(74) такие вещи решаются либо держанием штатника с соответствующими допусками/подписями либо решается на рабочем месте сотрудника куда приходит программист  и сотрудник через плечо смотрит чтобы программист не лез смотреть какой гепатит А или Б у его коллеги...

(76) ты ветку с начала читал?
ИМХО шифрование только ключа связи с таблицей пациентов решает этот вопрос

а вообще - поинтересуйтесь на православненьком - там автор по больницам специализируется..
всяко уже решали вопрос с сертифицированием по классам.
подскажет чо умное не из "теории" а из реальной "практики"

(78) ну да..
тебе приходит жалоба: печатается не то.

дальше
что будешь делать?

(79) вы это щас с кем разговариваете?

(81) а ты мне тут не выкайте :)

с тобой, с тобой разговариваю..

ты уж определись что тебе надо - защита от левых программистов чтобы данные не слили или все же закону соответствовать и сертификацию пройти

положить в общий зашифрованный модуль функцию, которая была бы привязана к имени сервера(+ еще че) и возвращала по хешу от имени сервера и Физлица его ГУИД на обезличенные персональные данные (полис например).

(80) в 99% все данные у меня есть в документе
если нужны данные пациента, прошу ключик достать из сейфа у начальника отдела

(82) это значит что я тебя совсем не понял - че такое православненький?

(83) да да.. а то тупой любопытный прог не догадается отладчиком жмакнуть и посмотреть.. ага..
или скормить на входе данные от интересующего его лица..


точно..

пишите мегафункции.. только делается подмена ВХОДЯЩИХ данных и вуаля - ваша функция выдает все что нужно

(85) http://1c8.livejournal.com/

еще раз: если козлов в огород пустили то поздно прятать качаны копусты..
чонить да пообкусают..

(86) шифровать УИН криптопро - ключ на флешке
как получить данные Иванова Ивана Ивановича с УИН?
или кто это в этом документе пациентом если есть только зашифрованый УИН, а шлешки с ключем нет

(89) флешка умерла, забыта в другом халате дома и потерялась.

дальше что?
база со 100500 человек превращается в тыкву?

(90) насколько знаю ключи можно новые создать, задать время жизни ключей (менять раз в месяц)

+ как без этой флешке программист будет отлаживать механизмы базы?
ну например механизм печати или чтения какогонить там больничного листа, где на входе пользователь ФИО пишет а на выходе получает часть секретных персональных данных в распечатке

?

(92) это да - но это контролируемый доступ - мы с этим готовы смирится

(90) вот у меня ключ есть от клиент банка - если я ключ потеряю - то все, хана?

(94) с клиент банком ты можешь снарядить своего гендира.. он ножками дойдет до банка, там напишет бумажку и тд и тп и через пару суток получите свой ключ.


тебе не кажется что системы в больничках несколько не могут такие временные потери переваривать?

+(93) т.е. если я dt унесу домой - то все ок

(95) вполне возможно сделать на этот случай запас ключей хранящийся в сейфе у заведующих отделений
потерял - к заведующему - за новым ключем, и звонок в асу для того что бы потеряный ключик заблокировали

(97) сертифицировать ты это как планируешь? :)

(95) зачем нам за нашими ключами идти в банк? -
(98) что сертифицировать - по ФЗ - это не моя задача

а ведь достаточно было 1 раз написать обфускатор персональных данных и выдать его лицу ответственному за выдачу демокопий программистам..

:)

Я бы не стал рздавать базы злоумышленникам, как украсть сиквельную базу слабо представляю, что за бред в 0 написан непонятно

(100) ага.. а был бы умнее показал бы ФЗ и сказал что при соблюдении оного такой задачи не должно стоять в принципе :)

(100) ну до этого нам расти и расти

тема рассматривается как дополнительная опция по защите данных
мало-ли где может дыра быть

(103) куда расти? он на ИТСе лежит
интерфейс ему сделай упрощенный с преднастройками и все

(104) ну рассмотрите опцию "украли базу с ключем"

не ну серьезно.. и что дальше

я злоумышленник.. у меня есть дт и ключ.

а вообще я автора понимаю..
долго вынашивал идею..
наверное пока с работы до дома ехал в автобусе и метро все думал - а как бы извернуться и решить задачу..

придумал.. поапладировал себе мысленно.. решил на форуме похвастаца а тут ему ушат холодной воды бац и оказывается что по сути зря старался - смысла в задаче изначально нет.

и остается изовсех сил цепляться за "нужность" задачи :)

кстати всегда делая всякие шифрования и офбуксаторы - задумайтесь что будет если ключ потеряют?

(109) ага. в больнице с ее объемами и скоростью ввода данных и потоком "клиентов/заказов" это особенно прикольно :)

(0)
А в чем сложность то?

(33) Например http://www.intersystems.com

(0)

Допустим есть справочники физ лица и история болезни.

Добавляем реквизиты с типом число и рарядностью1
&Цифра1
&Цифра2
&Цифра3
&Цифра4

Заполняем их простым счетчиком, главное чтобы не было повторяющихся вариантов.

Запрашиваем пароль при входе из 4-х цифр

Связываем справочники по примитивному алгоритму:

ИсторияБолезни.Цифра1=Физлицо.Цифра1+ЦифраПароля1;
ИсторияБолезни.Цифра1=?(ИсторияБолезни.Цифра1>9,ИсторияБолезни.Цифра1-10,ИсторияБолезни.Цифра1);


Далее в любом запросе  
Выбор Когда Физлицо.Цифра1+&ЦифраПароля1>9 Тогда
Физлицо.Цифра1+ЦифраПароля1-10
Иначе
Физлицо.Цифра1+ЦифраПароля1
Конец

Полученные данные сопоставляем с историей болезни.

Мало четырех цифр, сделай 128.

Вопрос только как этот пароль сохранить, чтобы вместе с базой не уперли.

(122) у вас оно русифицированно, сколько стоит
профосмотры есть7

(114) http://intersystems.ru/casestudies/by-industry.html#healthcare

(113) а упереть без проблем, если хоть один ключ можем сопоставить - сам там был 01.01.12 у врача такого-то - то ...

(116) Сделать промежуточный справочник.

Число А физ лица
Число Я истории болезни.

Число А преобразуется одним паролем в Б, по числу Б находится элемент в дополнительном справочнике, там получается число Э которое с другим паролем преобразуется в Я

Зная числа А и Я, и не зная паролей найти элемент которые им соответствует в дополнительном справочнике, не получится.

На самом деле, воровство базы - это только одна из угроз персональным данным.
Если хочется соответствовать закону, то нужно ещё позаботится о невозможности искажения и потери персональных данных, что в случае с ключом шифрования как раз и происходит - если кто-то хочет, чтобы база была уничтожена, то ему нужно просто сломать ключ, и всё - данные превращаются в тыкву.
Также немаловажным вопросом хранения медицинских данных является невозможность искажения данных врачом или программистом уже после приёма пациента, то есть, например, если кто-то захочет приписать документ к конкретному пациенту, то у него это не должно получиться.
Кроме того, важным фактором является протоколирование любого доступа к персональным данным - и в случае работы программиста с базой нужно обеспечить не невозможность что-то посмотреть, а запись всех действий по посмотрению, чтобы потом можно было спросить с человека, а зачем он это делал.

Что касается хранения данных, то вообще зачем в документах хранить какую-то ссылку на пациента или в пациенте хранить какую-то ссылку на документы даже зашифрованную.
Мы имеем медицинскую базу, где записан каждый приём пациента, но без привязки к самому пациенту. Разные медицинские услуги одному пациенту вообще никак не связаны между собой. По этой базе мы будем собирать статистику по всяким обращениям, болезням и т.п.
В другой базе живут пациенты с их персональными данными, то есть ФИО, номера страховок и прочие данные, характеризующие пациента, чтобы его можно было найти. К ним должен быть ограниченный доступ, так как просто получение этой базы может много рассказать о пациентах (причём не медицинской информации).
Далее, мы имеем третью базу, которая шифрована, но она хранит связи между номерами (идентификаторами) пациентов и номерами документов (или других объектов), которые описывают медицинские данные пациента. Для получения информации о том, кого лечили в данном документе, мы обращаемся в базу связи, для получения информации о том, от чего лечился данный пациент, мы обращаемся в базу связи. База связи может жить на шифрованном диске и использовать для доступа к ней аппаратные ключи шифрования и проверки подлинности, и в ней же выполняется журналирование всех запросов. Причём, трафик между базой связи и рабочим местом оператора должен быть шифрованный, так как в противном случае, просто прослушивая сетевой трафик можно получить часть базы данных.
Удачи.

(118) шифрованая база умирает и досвидос..
а еще прикольно разруливать быстродействие и возможные коллизии связей между тремя базами.

а вообще идея здравая, только баз нужно делать не три а 18

в первой базе фамилии
во второй имена
в третьей отчества
в четвертой пол
в пятой имена (поддельные чтобы запутать воров)
в шестой адреса
...

...
в 15ой дата приема
в 16ой ложная дата приема
в 17ой диагноз
в 18ой настоящий диагноз


это все обслуживаться должно 17тью специальными базами которые по специальному паролю будут шифровать ключи связи между 18тью основными базами.

(119) А кто мешает сделать шифрованной базе BackUp ?

Потом, если строго говорить о защите персональных данных, то нужно строить модели угроз и оценивать их вероятность.
Например, если сопрут комп со всеми базами и всеми ключами (или несколько компов).

Потом, вмешательством в частную жизнь можно считать даже обнародование самого факта посещения пациентом клиники, то есть любой список ФИО - уже нарушение.

Кстати, за федеральные базы данных для государственных медицинских учреждений собирается бороться Ростелеком, правда, они намекают, что для реализации нужно подзаконные акты поправить (ну, и, может быть, закон о персональных данных тоже).