Как организовать раздельное хранение данных? #741034

Ситуация - мод учреждение имеет программный комплекс для обработки медицинской информации. Задача - уменьшить риски при попадании базы в посторонние руки. как вариант рассматриваем разделение данных данные позволяющие идентифицировать физ. лицо и данные о здоровье в 1С появился такой тип метаданных - как внешние источники, но внешний источник вроде как не может быть ссылочным типом - т.е. его нельзя запихнуть в реквизит документа. как сделать так, что бы врач работая с документом описания состояния здоровья - видел ФИО и дату рождения пациента а при разрыве связи между двумя базами - "Объект не найден ...."?

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

мед учреждение

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

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

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

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

А какой интерес представляет ФИО + день рождения? Вот если рвач еще телефон видит то да.

а искать как будете в списке?

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

[ но это потребует извращений при написании интерфейсов и отчетов] конечно требует и пользы от разделения ни какой

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

Некорректный пример. У тебя есть бутерброд с колбасой. А вокруг голодные коты и птицы и ты следишь, чтобы его не сперли. А теперь ты положил колбасу отдельно и хлеб отдельно.

Но наибольшую ценность представляет сочетание того и другого вместе в лапах одного животного. Интересная задача, думаю, надо сначала не среди одинэсников поискать решения.

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

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

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

Все делать средствами 1С. А именно клиент-серверный вариант. Базу скуля хранить на отдельном серваке, без физического доступа фиг скулевую базу украдешь.

и пентагон ломают, не обольщайся

Изучить 152ФЗ... найти от 200 тыщ до 2 лямов смотря от класса

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

Другое дело, что автор может такое в адинесине накрутить, что ковыряться в этих данных желающих не найдется, проще утащить у другой клиники. И еще нюанс: что именно есть "риск"? Если телефоны уйдут спамерам без истории болезни - это какой риск? Или надо исключительно защититься перед ФЗ?

Так и внешние данные тоже, какая разница

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

+ Тем, кто будет наполнять НСИ (девочки или бабушки в регистратуре), при любом раскладе придется давать доступ к данным и тут насрать, где физически данные лежат - у них будет доступ.

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

у девочек в регистратуре не должно быть возможности слить всю базу... только чтобы по 1 записи могли видеть/править ))

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

Мдааа... собралися и обсуждают защиту персональных данных )) не сталкиваясь реально с этим геморроем

для этого доступ к базе они должны получать через сервер приложений или через вебсервер И права администрирования - только у настроящего администратора. Право на "Вывод" у них не отберешь, т.к. им документы печатать надо. Но это и хрен с ним - им ведь ни чего не мешает запомнить или на бумажку ручкой выписать все, что надо, так что технические ухищрения тут беспомощны

зачем бумажка - скрин экрана)

врачи скриншот делают ручкой на бумаге. У них там своя атмосфера всегда

Во-первых, разделение баз удобно будет только в том случае, если есть врачи, которые работают с медицинскими данными, но не интересуются персональными (например, выполнение анализов по пробиркам и занесение материалов в базу). Если все работают с данными пациента, то разделение ничем не спасёт. Во-вторых, по закону, нужна сертификация системы на соответствие определённому классу, а для этого нужно рассматривать модели угроз и способы противостоять им. То, что врач, который априори имеет доступ к информации, может что-то из неё унести - к данной модели не относится, так как он также должен отвечать за сохранность информации. Чтобы базу не унесли целиком - к ней не должно быть доступа у обычных пользователей, то есть ставить SQL-версию, и нормальные пароли администраторов. Шифрование данных, конечно, дело хорошее, но для этого нужно специальное решение, так как все попытки простого шифрования спасают только от простого просмотра файла базы по F3. Начинать работу нужно с того, чтобы приучить сотрудников работать не с ФИО пациента, а с его номером карты или идентификатором, чтобы соответствие между данными знали только те врачи, которые ведут непосредственное общение с пациентом. И, самое главное, в нормальных системах, где бояться утечек, нет никакого просмотра персональных данных на экране в виде списка, который можно успешно фотографировать.

давайте - что делать я решу сам сейчас я спрашиваю - как сделать именно разделение и о ФЗ сейчас разговор не ведется только волею пославшей меня ... только для уменьшения риска слива информации SQL конечно хорошо но база в постоянно разработке, постоянная нехватка времени - и dt найти с полной базой у нас в сети не сложно и потом - иметь отдельную базу с обезличенной мед информацией очень удобно - захотел врач писать дисертацию - нужна ему выборка - да пожалуйста а при привязке к персональным - фигу, надо сначала обезличить

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

просто непонятно зачем решать проблему каким то разделением, когда требуется по закону 152ФЗ ее решать совсем иначе?

Врачу на диссертацию я бы вообще ничего давать не стал - только выписки из карт пациентов, которых он лечил. Всё остальное - крайне нежелательно. Если уж очень хочется, то делайте доступ через Web-сервис из одной базы в другую за реальными данными. Кроме того, вводим справочник "Посетителм", куда по приходу пациента в клинику проставляются его персональные данные и связываются по Ид с данными в базе. Соответственно, пациент ушёл - данные о посещении сохраняются в удалённой базе через Web-сервис, а в базе остаются только данные посещения, привязанные к Ид посещения. Даже если унесут базу, то без связи Ид они и историю болезни одного пациента не восстановят.

Используй внешний источник данных, коль так хочется развлекаться. Придумай ИД, который будет идентифицировать, то тут то там информацию. По существу ссылка у справочника это только набор символов ;)

А если поделить еще на 3 вида информации, то и шифровать нечего не придется :) Ну а коль пошла такая пьянка, то можно еще поиграться шифрованием информации. Шифровать ФИО, номерки карт, телефон и Адрес. В таком же порядке можно и БД поделить :)

+ А если еще посмотреть в даль, то после написание этого зоопарка застрелить Программиста. Что бы никто не знал, что куда делится и как восстанавливается :)

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

добавить запись в карточку: "предположительная дата смерти ТекущаяДата"

" и dt найти с полной базой у нас в сети не сложно " - О_о. Люди занимаются безопасностью и выкладывают в шаре дтхи базы?

не отвлекай тс он в сферическом ваккуме коня ищет

Создать две базы - инфа персоналий, инфа по болезням. связь по ID. И одна к другой по OLE за инфой шастает. Не?

Для уменьшения "риска спереть" и существуют требования ФЗ к защите системы обработки ПДн. Разделение данных само по себе не панацея, а только одна из возможных мер. Если по сути вопроса, то разделить - не большая проблема. Проблема потом соединять. Реализовать совместную обработку можно через COM подключение. На сервере написать функции типа НайтиПациентаПоИД и дергать их при создании форм. Тогда клиентская часть почти не потребует доработок. Конечно придется все это кэшировать где-нибудь в параметрах сеанса. Мороки прилично будет. Другая проблема - транзакционная целостность при изменениях. COM соединение, если не ошибаюсь, не умеет протокол 2PC.

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

Ммм, можно развить идею Начнем с того ПДн это когда можно однозначно идентифицировать личность. Т.е. "Фамилия" это не ПДн как и список фамилий. Делим базу по хранимых значениям на разные справочники (каждый из которых не является ПДн сам по себе) Отдельно справочник фамилий, отдельно имен и отчеств, так же отдельно храним телефоны. Причем все в открытом виде. А вот в закрытом (зашифрованном) виде храним только связки между этими справочниками. Т.е. справочник скажем "Пациенты" имеет наименование в виде к примеру "И*****в И**н И******ч" и несколько шифрованных ссылок-индексов на нужные записи из справочников "фамилии", "имена", "отчества", "телефоны", "снилсы" и т.д. И наоборот каждый из таких "не шифрованных" но не ПДн справочников имеет зашифрованную вторым ключем ссылку на "Пациенты" Получается и индексы можно сделать т.е. искать телефонам и т.д. и данные разделены ЗЫ Осталось придумать понадежнее с ключами

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

насчет в несколько записей заглянуть это верно, но не совсем )) да придется для всех найденных записей (фамилия, имя, отчество) ссылки на "пациента" расшифровать и сравнить, выбрав только те у которых совпадают но вообще то даже целиком ФИО не является в обычном случая ПНд без скажем даты или года рождения т.е. задачка усложняется проектирования структуры чтобы учесть требуемые поиски/выборки

+ да ищем то по "незашифрованным" данным которые не увязаны в ПНд к примеру некий список из номеров телефонов в открытом виде ПНд не является без привязки к ФИО или адресу

ПНд = ПДн ))

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

Существуют ли методы шифрования с поддержкой поиска по зашифрованным данным? Причем реально надежные? К примеру строка которую ищем так же шифруется и ищется уже совпадения в шифрованных строках. Или подобное сразу теряем всю надежность шифрования?

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

Если у вас в сети все что угодно можно найти, то никакое разделение данных вам не поможет. Наводите порядок в сети.

Рома, вы чет прыгаете с одного яйца на другое, тебе Программу писать или Защиту от "Украл сис-админ весь HDD" (и хоть ты упрятайся :))

+ Ты лучше сперва БД раздели. А уже потом думай, как учет организовать. Хотя лучше Учет организовать, а уже потом делить, шифровать, или заниматься другой бестолковой деятельностью. Похоронные конторы держат связь с людьми, а не с БД. ... это я так, к тому, что Данные если нужны, то их получат...