![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
![]()
Сообщение
#1
|
|
Группа: Пользователи Сообщений: 1 Регистрация: 2.12.2007 Пользователь №: 4587 ![]() |
Никому не попадались программы для ведения базы данных о пациентах (другими словами, программное обеспечение для клиник), где бы можно было вносить диагнозы, назначаемое лечение, дату повторного визита и пр.?
Или дайте ссылки на эти ресурсы (желательно бесплатные) или тематические форумы. Заранее спасибо. P.S.: может быть это вопрос и не для этой ветки форума, но более подходящей я не нашел ![]() |
|
![]() |
![]() |
![]() |
![]()
Сообщение
#2
|
|
![]() Группа: Пользователи Сообщений: 1141 Регистрация: 10.04.2007 Пользователь №: 4040 ![]() |
В связи с вступлением в силу с 1 января 2010 года законодательства о персональных данных всю представленную в теме информацию о госпитальных информационных системах следует дезавуировать. В настоящее время ни одна (!) госпитальная система, эксплуатирующаяся на территории России, не соответствует требованиям и не сертифицирована в установленном законом порядке в ФСТЭК (т.е. отсутствует в списке сертифицированных продуктов на сайте ФСТЭК). Следовательно, начиная с указанного выше срока, эксплуатация всех госпитальных информационных систем во всех клиниках России незаконна, подпадает под действие Кодекса об административных правонарушениях со всеми вытекающими правовыми последствиями для руководства клиник и должна быть прекращена.
Если уважаемых коллег заинтересовала данная информация, могу предоставить все необходимые ссылки на информационные ресурсы (за исключением 4-х документов ФСТЭК с грифом ДСП). Приглашаю также обсудить меры по решению проблемы. Сообщение отредактировал Игорь - 16.05.2009 - 14:46 ![]() Ebsignasnan prei wissant Deiws ainat! As gijwans! Sta ast stas arwis!
|
|
![]() |
![]() |
![]()
Сообщение
#3
|
|
Группа: Пользователи Сообщений: 53 Регистрация: 22.06.2007 Пользователь №: 4178 ![]() |
В связи с вступлением в силу с 1 января 2010 года законодательства о персональных данных всю представленную в теме информацию о госпитальных информационных системах следует дезавуировать. В настоящее время ни одна (!) госпитальная система, эксплуатирующаяся на территории России, не соответствует требованиям и не сертифицирована в установленном законом порядке в ФСТЭК (т.е. отсутствует в списке сертифицированных продуктов на сайте ФСТЭК). Следовательно, начиная с указанного выше срока, эксплуатация всех госпитальных информационных систем во всех клиниках России незаконна, подпадает под действие Кодекса об административных правонарушениях со всеми вытекающими правовыми последствиями для руководства клиник и должна быть прекращена. Если уважаемых коллег заинтересовала данная информация, могу предоставить все необходимые ссылки на информационные ресурсы (за исключением 4-х документов ФСТЭК с грифом ДСП). Приглашаю также обсудить меры по решению проблемы. Было бы интересно познакомиться с такими документами. У нас (Белоруссия) пока до этого дело не дошло (к сожалению). Но, думаю, вскоре также будут подвижки в этом направлении. По существу. Вся информация госпитальной системы хранится в БД. Рискну предположить, что для более-менее крупной системы это будет из коммерческих: MS SQL сервер, Oracle, 4D, из бесплатных: mysql, PostgreSQL. Как мне видится, в случае MS SQL сервер, Oracle проблема хранения, регламентации доступа прозрачно решается на уровне сервера и/или сервера приложений (возможно, с приобритением дополнительных модулей). В случае с Oracle регламентация может вестить "в особо извращенном виде ![]() При использовании mysql, PostgreSQL Нужно будет шифровать поля с персональной информацией и реализовывать механизм организации доступа. Это приличные переделки в ПО. Остается открытым вопрос передачи персональных данных по сети. В случае с Oracle есть прозрачное решение. Как в SQL server -- не знаю. |
|
![]() |
![]() |
![]()
Сообщение
#4
|
|
![]() Группа: Пользователи Сообщений: 1141 Регистрация: 10.04.2007 Пользователь №: 4040 ![]() |
Было бы интересно познакомиться с такими документами. У нас (Белоруссия) пока до этого дело не дошло (к сожалению). Но, думаю, вскоре также будут подвижки в этом направлении. К сожалению? Святая наивность! http://www.iksmedia.ru/blogs/post/449145.html Это еще минимально радикальное мнение. Я уже цитировал п. 1 ст. 22 Закона 152. Процитирую п. 2 этой же статьи: "Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: ... 2) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных; ...". Т.е., достаточно заключить с пациентом договор (а многие клиники так и делают) на оказание медицинских услуг - и можно использовать для информационной защиты стандартные (возможно, несертифицированные), но эффективные средства, не получать лицензию на защиту информации и т.д. Кстати, в договоре учесть согласие на передачу данных в установленном законом порядке. Наверное, это является основанием того, чтобы все существующие медицинские информационные системы (МИС) могли быть выведены "из-под удара" Закона. Это мое личное мнение. Однако некоторые авторы так не считают, а напротив, утверждают, что МИСам должна быть установлена максимально возможная конфиденциальность и максимальная группа по защите персональной информации (= максимально возможные затраты, ведущие к полной нереализуемости МИСов в существующих условиях, что, впрочем, самими авторами и признается). См., например, http://www.consultant.ru/online/base/?req=...MED;n=31473;p=1, а также http://www.consultant.ru/online/base/?req=...ase=MED;n=29496. Сообщение отредактировал Игорь - 3.06.2009 - 18:00 ![]() Ebsignasnan prei wissant Deiws ainat! As gijwans! Sta ast stas arwis!
|
|
![]() |
![]() |
![]()
Сообщение
#5
|
|
Группа: Пользователи Сообщений: 53 Регистрация: 22.06.2007 Пользователь №: 4178 ![]() |
К сожалению? Святая наивность! http://www.iksmedia.ru/blogs/post/449145.html Это еще раз доказывает, что основной угрозой для информационной системы прежде всего являются вполне легальные с точки зрения системы пользователи. |
|
![]() |
![]() |
![]()
Сообщение
#6
|
|
![]() Группа: Пользователи Сообщений: 1141 Регистрация: 10.04.2007 Пользователь №: 4040 ![]() |
Это еще раз доказывает, что основной угрозой для информационной системы прежде всего являются вполне легальные с точки зрения системы пользователи. Совершенно верно, но не обычные пользователи. Скопировать целиком базу данных, а именно такие проблемы и случаются время от времени, может только ее администратор. Стандартные организационные и программно-технические средства (применявшиеся до принятия закона и применяемые сейчас) обеспечивают достаточную защиту персональных данных. Законодательство, существовавшее до принятия означенного закона, обеспечивает полную правовую защиту. Было бы желание - можно и вычислить, и наказать, в соответствии с действующим законодательством, администратора, поставившего на рынок базу данных ГИБДД или налоговой службы. Если администраторы упомянутых баз данных имели возможность безнаказанной кражи этих самых данных данных до принятия обсуждаемого пакета законов, точно также они будут иметь такую возможность и после принятия и вступления в действия данного пакета законов, независимо от того, имеет Windows рабочей станции сертификат ФСТЭК или нет, сертифицирован файервол или нет. В любой БД ФИО хранится только как информационное поле (правда, может использоваться для связывания с другими БД) и используется для поиска. Вся информация, относящаяся к пациенту, связывается по паре первичный-внешний ключ. Таким образом, если первичный ключ продублировать на ИБ, возможна однозначная идентификация пациента. Особенно, если первичный ключ будет формироваться по определенным правилам и с ИБ вводиться посредством считывания штрих-кода. Речь идет о том, можно ли идентифицировать пациента по записи в базе данных, из которой (из записи) удалены поля ИМЯ, ФАМИЛИЯ, АДРЕС, НОМЕР ПОЛИСА и т.д. Причем идентифицировать БЕЗ ПРИВЛЕЧЕНИЯ дополнительной информации. Естественно, если в бумажной ИБ имеется паспортная часть, содержащая номер записи в электронной ИБ (этим номером может быть хоть номер истории болезни, хоть некое случайное число, записанное хоть числами, хоть штрих-кодом - который на самом деле является просто особым шрифтом, хоть и тем, и другим одновременно - неважно), то понятно, что эта запись относится к данному пациенту (иначе вообще зачем нужна эта МИС). Запись в ЭИБ без паспортной части как раз и будет обезличенной. И этот подход считаю единственным, позволяющим формально выполнить закон (ценой некоторого снижения функциональности) без привлечения финансовых средств, которых, собственно, и так нет. Сообщение отредактировал Игорь - 5.06.2009 - 12:50 ![]() Ebsignasnan prei wissant Deiws ainat! As gijwans! Sta ast stas arwis!
|
|
![]() |
![]() |
![]()
Сообщение
#7
|
|
Группа: Пользователи Сообщений: 53 Регистрация: 22.06.2007 Пользователь №: 4178 ![]() |
... Если администраторы упомянутых баз данных имели возможность безнаказанной кражи этих самых данных данных до принятия обсуждаемого пакета законов, точно также они будут иметь такую возможность и после принятия и вступления в действия данного пакета законов, независимо от того, имеет Windows рабочей станции сертификат ФСТЭК или нет, сертифицирован файервол или нет. Есть технологии, позволяющие исключить подобное со стороны БДА, -- у Oracle -- DB Vault, у MS -- управление на основе политик (SQLServer 2008). Правда не знаю, сертифицировано ли это. Но стоимость подобных решений высока. |
|
![]() |
![]() |
![]()
Сообщение
#8
|
|
![]() Группа: Пользователи Сообщений: 1141 Регистрация: 10.04.2007 Пользователь №: 4040 ![]() |
Есть технологии, позволяющие исключить подобное со стороны БДА, -- у Oracle -- DB Vault, у MS -- управление на основе политик (SQLServer 2008). Администратор в любом случае может скопировать базу данных целиком. А именно целиком она и представляет интерес для злоумышленников. Таким образом, найдя на рынке соответствующее предложение, у правоохранительных органов не должно быть проблемы в поиске, кто виноват в краже - это только администратор баз данных учреждения - его и нужно сажать в тюрьму. Правда не знаю, сертифицировано ли это. Но стоимость подобных решений высока. Вот что дает соответствующий запрос на сайте Oracle http://www.oracle.com/technology/deploy/se...valuations.html. Т.е., ознакомившись с сертификатами (почти 10 лет, как просроченными), можно сделать вывод, что сертифицированы (предшественником ФСТЭК) не серверы Oracle как таковые, а 2 (!) конкретных экземпляра Oracle, под конкретную конфигурацию оборудования (UNIX сервер HP) и с конкретным дополнительным ПО. Из данной информации делаем вывод, что ни одно решение по МИС, предлагаемое ныне на данном рынке, требованиям не соответствует. Хотя конкретное решение может быть сертифицировано самим разработчиком прикладного ПО, информации о такой сертификации не представлено. Сообщение отредактировал Игорь - 30.06.2009 - 13:50 ![]() Ebsignasnan prei wissant Deiws ainat! As gijwans! Sta ast stas arwis!
|
|
![]() |
![]() |
![]()
Сообщение
#9
|
|
Группа: Пользователи Сообщений: 53 Регистрация: 22.06.2007 Пользователь №: 4178 ![]() |
Администратор в любом случае может скопировать базу данных целиком. А именно целиком она и представляет интерес для злоумышленников. Таким образом, найдя на рынке соответствующее предложение, у правоохранительных органов не должно быть проблемы в поиске, кто виноват в краже - это только администратор баз данных учреждения - его и нужно сажать в тюрьму. В том то и дело, что при использовании DB Vault (и его аналогов) администратор, имея доступ к физическим файлам, доступа к данным может и не иметь (в отличие от ситуации, когда DB Vault не установлен). Т.е., физическое копирование файлов не имеет смысла. |
|
![]() |
![]() |
![]()
Сообщение
#10
|
|
![]() Группа: Пользователи Сообщений: 1141 Регистрация: 10.04.2007 Пользователь №: 4040 ![]() |
В том то и дело, что при использовании DB Vault (и его аналогов) администратор, имея доступ к физическим файлам, доступа к данным может и не иметь (в отличие от ситуации, когда DB Vault не установлен). Т.е., физическое копирование файлов не имеет смысла. Действительно, по данным Интернета (кстати, ни слова на официальном сайте Oracle - следовательно, сертифицирована не серия - см. ниже) Oracle 11g R1 (11.1.0.7) + опция Database Vault сертифицирована (номер сертификата 1849 от 25.05.2009) по требованиям ФСТЭК России для защиты персональных данных (152-ФЗ) до класса 2, включительно. Но в данной информации опять же - непонимание сути сертификации в России. Если одна копия, представленная на сертификацию, сертифицирована, то это не значит, что сертифицирована вся серия продуктов (хотя такое и возможно). При покупке продукта нужно учесть, что 1) у конкретного образца должен быть сертификат и 2) срок действия сертификата ограничен. Т.е., после окончания срока действия сертификата придется 1) приобрести новый продукт или 2) продлить сертификат на конкретный продукт (тут могут быть сложности - например, в свое время была сертифицирована Windows XP SP1 - сегодня о безопасности такой системы можно рассуждать лишь с улыбкой; грубо говоря, продукт портится со временем, т.к. изобретаются новые угрозы, что справедливо и удостоверяет сертификат). Еще немного о сертификации. Скажем, вы ставите на компьютер сертифицированную версию Windows и намерены безопасно работать в Интернете... если вы, конечно, информационный "самоубийца" - минут на 5 вас хватит. Вы не можете установить сертифицированную версию Windows и безопасно работать, не установив дополнительно файервол и антивирус. Т.о., хоть какая-то минимальная безопасность обеспечивается при наличии других программных продуктов, помимо сертифицированной версии Windows. Вот мы и доказали, что сертификация одного продукта - профанация идеи информационной безопасности. Сертифицироваться должен конкретный программно-аппаратный комплекс + комплекс организационных мероприятий, и никак иначе. Причем сертификация касается всей номенклатуры применяемых программ - например, хочешь ICQ на рабочем месте - сертифицируй ICQ во ФСТЭК - причем и сервер в Калифорнии, и все 30 млн. клиентов. Хочешь mail.ru агента - аналогично. Хочешь Total Commander - и его тоже. Захотел Microsoft Office - есть сертифицированная версия. А захотел статистику посчитать в AtteStat для Excel - сертифицируй AtteStat (обратите внимание на последний раздел Лицензионного соглашения AtteStat - он там с 2002 года). Вот тут попалась информация по Database Vault http://www.aladdin.ru/press-center/publica...cation19697.php. Цитата из нее: "... проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault, но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Vault, т.е. проблема защиты от привилегированных пользователей сохраняется". Так можно бесконечно контролировать друг друга. Безопасная система должна быть построена так, чтобы ее невозможно (или не нужно) было украсть. Сообщение отредактировал Игорь - 1.07.2009 - 13:13 ![]() Ebsignasnan prei wissant Deiws ainat! As gijwans! Sta ast stas arwis!
|
|
![]() |
![]() |
![]()
Сообщение
#11
|
|
Группа: Пользователи Сообщений: 53 Регистрация: 22.06.2007 Пользователь №: 4178 ![]() |
...Сертифицироваться должен конкретный программно-аппаратный комплекс + комплекс организационных мероприятий, и никак иначе. Вот тут попалась информация по Database Vault http://www.aladdin.ru/press-center/publica...cation19697.php... 1. Я как раз об этом и писал ранее. Более того, в сертификате (вернее, в сопроводиловке) должны быть оговорены и условия замены оборудования в случае выхода из строя каких-то компонент. И Вы совершенно правы, что, если брать ad maximum, то можно, к конце концов, дойти до маразма. 2. Лично я указанную информацию с aladdin'а воспринимаю с хорошей долей скептицизма. Причина проста -- предлагаемые ими продуктыявляются конкурентами, в частности, DB Vault. Одна из причин разработки средств типа DB Vault -- избыточные полномочия администратора БД. Желаемый принцип -- администратор БД должен управлять БД, а не ее содержимым. Происходит разделение полномочий: админ может скопировать файлы, но не может получить доступ к информации. Офицер по безопасности (в терминах Оракл) имеет доступ к управлению видимостью информации, но не имеет доступа к файлам. |
|
![]() |
![]() |
![]() ![]() |