Интересный анализ опубликован у нас на сайте. В нем проводится исследование того, какие длины ключей для каких криптоалгоритмов являются адекватными на сегодняшний день и на ближайшие 3-4 года. Конечно про ГОСТ там ни слова, но все равно интересно. Хотя хочу заметить, что для большинства приложений DESа по-прежнему хватает за глаза ибо ломать криптографию в лоб мало кому нужно и захочется.
Жаль, что ФСБ такого публичного анализа не имеет.
- Posted using my iPhone
Подписаться на:
Комментарии к сообщению (Atom)
24 коммент.:
OMG, кто-то открыл для себя существование критерия Ленстры? Леша, http://www.keylength.com/ существует довольно давно и куда более полон информацией.
ivlad: +1 :)))
Ну я ж не криптограф ;-) Я прочел в нашем блоге - мне понравилось - я отпостил ;-)
Здравствуйте, Алексей.
Извиняюсь, что не в тему пишу в комментах, просто не нашел вашего емайл.
У Вас в блоге много интересной информации относительно ПД. Я студент компьютерной безопасности, пишу курсовой проект по защите ПД. В частности решаю вопрос по оптимизации информационно-вычислительной сети в контексте её приведения в соответствия требованиям 152-ФЗ. Возникло несколько вопросов.
Главный вопрос: Можно ли с помощью обезличивания ПД снизить класс ИСПДн?
Четко ни где не сказано, что понимать под обезличиванием.Не ясно, должно ли такое преобразование быть необратимым.
Например, можно ли сделать 2 БД: в одной только ФИО и id, в другой id (или хеш id, для необратимости) и дополнительная информация (номер паспорта, прописка, зарплата, страховка и любая другая информация). Рассмотреть эти две БД, как две разные ИСПДн (поставить между ними МЭ итп) одна 3 класса (или даже 4 так как ФИО не позволяет однозначно идентифицировать субъект, по мнению некоторых нужна еще дата и место рождения), вторая 4 класса. Хотя вместе они были бы не ниже 2 класса. Как регуляторы смотрят на подобные решения? Как сделать корректной описанную выше процедуру (если это возможно), что бы все было законно?
Предпосылки к такому решению :
1. Методичка Минздрава по защите ПД в мед. организации содержит следующий пункт:
"Обезличивание. Введение в процесс обработки персональных данных процедуры обезличивания существенно упростит задачи по защите персональных данных. Обезличивание можно провести путем нормализации баз данных. После выполнения обезличивания защите будет подлежать (по требованиям регулирующих документов) лишь справочник, позволяющий выполнить обратное преобразование."
2. В документе NIST Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)" SP 800-122 регулирующем защиту ПД в Америке предлагается использовать обезличенную (de-identified) и анонимную (anonymized) ПД для уменьшения требований к системам защиты ПД. Вы писали про это года 2 назад, но вопрос тогда был спорный. Возможно сейчас Вам удалось на практике опробовать подобные методы и вы точно можете сказать как делать можно, а как нет.
Надеюсь на Вашу помощь.
С уважением, Денис.
e-mail: dnsknnv@gmail.com
Интересная идея. Denis.
Denis, а как по Вашему мнению, на рабочих местах, которые будут обрабатывать информацию из этих "обезличенных" БД, персданные тоже будут обезличенные?
Denis. Вы класс ставите не на базу данных, а на информационную систему. Если на рабочих местах Вы можете (через хэш или еще как) связать данные из разных баз между собой, то Ваша система имеет соответствующий класс.
Цель всех этих классов - уровень доступа к персональным данным человека пользователя информационной системы.
2 Joky
Да, это можно устроить. Я как раз сейчас разрабатываю схемы оборота информации которые позволяют избежать обработки на 1 рабочем месте не обезличенной информации.
Рассмотрим, например фирму которая занимается разработкой ПО на заказ. Тут будут ПДн сотрудников и ПДн клиентов.
Клиенты. Первый случай - юр. лица. Набор данных: № договора, номер счета юр.лица, юр и физ адрес юр.лица + общедоступные ПДн: ФИО сотрудника заключающего договор, его должность, номер рабочего телефона. Эти данные наверняка содержаться в визитках и на сайте юр.лица, каких-то рекламных материалах. Но при необходимости в договоре указать, что эти данные будут обрабатываться как общедоступные. 4 категория - проблем нет.
Клиенты. Второй случай. Физ.лица. При заключении договора с клиентом указывается псевдоним (или логин, кодовое слово) которое будет использоваться при обращении его в службу поддержки итп. В договоре будет содержаться кроме псевдонима вся необходимая информация что бы он имел юридическую силу (ФИО, адрес, паспортные данные), договор будет хранится в сейфе отдельно. Дальше. Псевдоним ставится во взаимно однозначное соответствие с идентификатором id.
БД1: псевд1<->id1.
Далее БД2. В этой БД содержится таблица связывающая каждый id с несколькими уникальными номерами id1 id2 id3... Либо же просто к id применяется хеш функция, но только с разными ключами (напомню, что хеш в общем случае это тоже самое, что блочное шифрование, только в последнем блоки исходного текста складываются с блоками ключа и выводятся, а в хеш преобразовании блоки текста складываются друг с другом и ни что не мешает первый блок текста сложить перед преобразованием с ключом или же последний). Либо просто добавить текст, вот так: Хеш("id1 + "номер счета""), где id1 это конкретный номер, а "номер счета" это и есть те самые слова "номер счета" (символы в определенной кодировке). Хеш можно как всякий раз вычислять по присланному id так и хранить в таблице значения, все зависит от соотношения производительность/дисковое пространство.
БД2: id1->хеш11,хеш12,хеш13...
Далее вся дополнительная информация хранится в разных БД (можно на одном сервере).
БД3: хеш11<->контактный номер телефона
Можно все и в одной БД хранить. При том даже без конкретного разделения полей по значению. числовую информацию хранить в одном столбце, вне зависимости от того возраст это номер дома или номер счета, так как хеш всегда будет уникальный для каждого значения. Но это плохое решение, так как для каждой ячейки в таблице нужен будет свой хеш. Например при хранении информации о клиенте такой как: какие заявки были, когда, какая проблема была, с каким ПО, как решилась, на сколько клиент добросовестный, были ли задержки по оплате и друге заметки о нем нужные для фирмы не может даже в совокупности его идентифицировать и ее можно хранить всю вместе, что бы на нее ссылался один хеш(id).
Все обозначенные БД есть не просто базы данных, а обособленные ИСПДн 4 класса, отделенные друг от друга межсетевыми экранами. Последнюю самую большую БД можно вообще на аутсорс вынести.
Теперь основные операции с клиентами физ.лицами.
Звонок в техподдержку. Звонящий называет свой псевдоним (и/или номер договора, хотя это избыточная информация) и описывает проблему. Составляется заявка где указывается №заявки, контактный телефон который даст звонивший, адрес, какое ПО, какая проблема. При этом не уточняется домашний это адрес, адрес регистрации, прописки итп, то есть мы не знаем как адрес и субъект ПД относятся др к др. Не уточняем рабочий или личный телефон. Что бы не указывать в заявке даже псевдоним можно создать какую то временную запись в таблице обрабатываемых заявок хеш(номер заявки)-> псевдоним. После выполнения заявки удалить информацию о телефоне и адресе, оставить только номер заявки, описание проблемы и ее решение. Из таблицы временных заявок получить псевдоним и по пути псевдоним <-> idN -> хешNN <-> (информация тех поддержки) добавить туда информацию оставшеюся в заявке с описанием проблемы.
Алгоритм немного громоздкий, но если его автоматизировать то будет работать как часы. Плюс придется забыть о правилах приличия и человек пришедший из тех поддержки будет здороваться примерно так:
"Здравствуйте, анонимный клиент, оставивший заявку номер такой-то! Я Иванов из техподдержки такой-то фирмы." =)
Оплата.
Оплата физ лицом должна приводится на счет фирмы с указанием в поле "от кого" псевдонима. Я не знаю, позволяют ли сейчас банки так делать своим физ.лицам, но вряд ли они паспорт просят при исходящем платеже.
Регуляторы придраться не должны. Можно вообще сервер с хеш<->какие то данные арендовать где нибудь в дата центре что бы было территориальное разделение и отвечали за него другие. Преобразование псевдоним <->id и id->хеши можно проводить на одном сервере в целях экономии. Это по закону будет ПДн 4 категории, они не позволяют идентифицировать субъекта ПДн в контексте данной ИСПДн но
Свои сотрудники. Тут все аналогично. Только при заключении трудового договора надо отметить что их ФИО должность и место работы, рабочий телефон будут общедоступными. Для хранения номера обязательного пенсионного страхования, что бы проводить отчисления в пенсионный фонд использовать схему с псевдонимами id хешами. Проблема может возникнуть только на этапе компиляции этих данных для отправки. Опять вопрос можно ли рассматривать ФИО + номер об.пен.страх как данные не определяющие субъекта. Вообще то серия и номер паспорта, номер обязат пенсион страхов НЕ определяют субъекта ПДн так как преобразование "серия номер паспорта" <-> "ФИО дата и место рождения" НЕВОЗМОЖНО. За это отвечает паспортный стол. В случае номера страховки - тот орган гос-ва который этим занимается.
Прошу обосновано критиковать описанную схему. Скорее всего я не все учел. укажите какие проблемы вы здесь видите.
2ZW
"Цель всех этих классов - уровень доступа к персональным данным человека пользователя информационной системы."
Почему вы так решили? СПДн защищается не столько от внутренних пользователей, сколько от внешних нарушителей.
Я просто не описывал организационные мероприятия и матрицу доступа. Понятно что она будет. Хотя тут ещё на первом этапе информация обезличивается за счет бумажного носителя (договора). Тот кто заключает договора может не иметь доступа к ИСПДн вообще. ФИО и паспортные данные клиента во время работы вообще не нужны. Только если будет судебное разбирательство.
Далее доступ разграничивается так, что бы работник call-центра имел доступ только на добавление данных определенному псевдониму. Техник имел доступ только к написанной в заявке информации. Итд.
как говорят =много букв..=, бегло почитал и запутался в сути Denis (что хотел сказать), можно и по кратче..
Denis,
прочитал только по диагонали, так же и отвечу:
1. все это теория годная для того чтобы создавать что-то с нуля. на практике процессы замучаетесь переделывать начиная от непонимая девочек почему они должны работать с anonym<6цифр> и до ...
2. как только вы затронете деньги - закончится ваша анонимность. Договор значит с Васей Пупкиным, а деньги от анонимов принимаете?
3. и опять же кадры свои вы как вести думаете: 2НДФЛ к примеру работник запросит? печатную машинку и счеты выдадите?
Денис, можно было изложить кратко:
"Если при работе с клиентом не требуется идентификация личности по ФИО (то есть достаточно псевдонима), то это позволяет оптимизировать большую часть системы до 4 класса."
Пример подобран хороший, соответствующий. Но метод далеко не универсален, как Вам возможно кажется.
Сразу навскидку проблемы в случае других ИСПДн:
1. А если при обращении клиента его необходимо однозначно идентифицировать? Например речь идет об учете финансовых средств. Здесь без проверки паспорта не обойтись а значит оператор должен видеть эти данные.
2. Оператору нужно выводить на печать документы для клиента. Официальный документ с "псевдонимом" это не комильфо...
3. Ну и не забываем, что необходимость изменения уже существующего технологического процесса, да еще так кардинально, требует слишком много ресурсов и времени, да и проблемы со стабильностью. Некоторые компании до сих пор сидят на 1С 7.7, потому что "работает? не трогай" :)
Смешно читать чушь
Вы прочтите Васенаарские соглашения
Кто же вам продаст реальный продукт - только погремушки с нулями в регистрах.
Вы у Джексона и Веника спросите насчет их поправки на поставку оборонных средств агрессивным коммунистам
Semen
to Denis: на практике обезличивание проходит на ура в случае, если сопоставление идентификаторов происходит при непосредственном участии человека. Скажем, в одной ИСПДн крутится ФИО + ID, во второй - ID + все остальное, а вот сопоставляет ИД человек. И пусть даже делает он это на одном рабочем ПК, с одной и той же клиентской программой, главное чтобы на ПК было 2 сетевые карты, персональный МЭ и соответствующим образом настроена маршрутизация. Вот тогда проверяющих все устраивает. Предложенная Вами схема - то же самое, только идентификация осуществляется исключительно автоматизированным способом. Тут уже возможны пенальти...
2 ЕвгенийКР:
покороче было в моем самом первом посте. тут та же идея только чуть более усложненная. больше идентификаторов.
2 Dimka9:
1. это пока только проект. важно установить имеет ли он право на жизнь с точки зрения текущих номинативных актов.
2. у анонима можно номер счета хранить. это уже что то.
3. по кадрам для этой формы просто собираем все данные обезличенные, распечатаем и потом в ручную можно вписать ФИО.
2 Евгений:
1. я не настаиваю на универсальности. но в большинстве случаев деньги можно принимать по безналичному расчету. у меня например договор с провайдерам на интернет включает логин и пароль, по ним я захожу в личный кабинет и оплачиваю услуги с помощью платежных карт или перевода с кредитки. а наличку можно исключить. это же не банк. для банков свой отраслевой стандарт есть, им ФСТЭК ФСБ и Роскомнадзор побоку уже.
2. в данном бизнес процессе на печать для клиента ничего не выводится. лес надо беречь) а вообще, со 152ФЗ комильфо измениться) как то на конференции по ПДн была поднята тема как представлять выступающих на ней. был предложен вариант "выступающий №(шесть цифр)"=) в шутку пока...
3. изменения не такие уж большие. два сервера, две СУБД и хеш.
2 Sid
не понял о чем Вы.. при чем тут Вассенарские соглашения? Используются обычные СУБД, обычный хеш. я рассматривал хеш ГОСТ Р 34.11-94. и я сам могу его реализовать и всю описанную систему тоже. тут ни какие высокие технологии двойного назначения не нужны =)
2 Алексей Волков
спасибо Алексей, очень ценное замечание, я его учту. мне вот и интересно как подобные вопросы на практике решаются! а то теоретических обсуждений в интернете много, а что на практике не вызвало у регуляторов возражений не пишет ни кто. собственно оно и понятно - закон то не вступил в силу ещё. я порылся в судебных решениях, но ничего по теме не нашел.
Не могли бы Вы предоставить дополнительную информацию? Если это возможно конечно... Где это работает (на каком предприятии)? Какой класс был заявлен и данные какой категории обезличиваются? Было ли аттестовано ФСТЭК (или была иная причина для проверки, ведь закон пока не действует)? Мне важно знать что слухи, а что факт.
Мой e-mail: dnsknnv@gmail.com
to Denis: ну, во-первых, закон уже работает давно - с 2007 года. Во-вторых, проверок ФСТЭК совсем мало, потому и нет информации. В третьих, аттестация ИС и защита ИСПДН - две совершенно не связанные между собой вещи. Так что придется довольствоваться мнением интернет-сообщества, ну и конечно учить матчасть :)
по кадрам для этой формы просто собираем все данные обезличенные, распечатаем и потом в ручную можно вписать ФИО.
я тебе просто в качестве примера привел. там еще куча всего где нужно масссово распечатать/сформировать файлики для всяких органов.
главное чтобы на ПК было 2 сетевые карты, персональный МЭ и соответствующим образом настроена маршрутизация.
вот тут то они и оторвутся :) Всякие сертифицированные аппаратно программные комплексы от НСД и для контроля целостности и тд и тп. ну и как бы одного ПК будет маловато. Не, я не спорю - вариант имеет право на жизнь, но нужно иметь ввиду что оутпостом тут не отделаешься.
to Dimka9: нет, не оторвутся. При таком раскладе имеем 2 ИСПДн 4 класса и одно неавтоматизированное рабочее место, так как без человека на нем сделать ничего вообще нельзя. Так что придут, поглядят и уйдут. Тут, по их методичкам, даже техсредства можно не ставить. Ни пароли, ни файрволлы. Это уж так, из ИБ-шных соображений. Собственно файрволл там совсем не для этого - а для того, чтобы окончательно разделить ИСПДн, что называется, "наглушняк по ФСТЭК-овски".
2 Алексей Волков
"...одно неавтоматизированное рабочее место, так как без человека на нем сделать ничего вообще нельзя."
АРМ: Программно-технический комплекс АС, предназначенный для автоматизации деятельности определенного вида.(ГОСТ 34.003—90).
Компьютер сам по себе уже АРМ. Он ведь автоматизирует какие-то действия. Человек же не бегает не смотрит инфу к базам данных. Компьютер эту информацию человеку предоставляет(отображает на дисплее) и временно хранит (хотя бы в оперативной памяти). Может как нибудь задание для принтера на печать готовить так, что бы ПДн подавалась с разных серверов и печаталась на одном листке. Хотя это бред... Устал я от этой неоднозначности. К кому можно обратиться за официальной точкой зрения? У ФСТЭК есть бесплатная горячая линия для пострадавших в ходе ознакомления с 152-ФЗ?)
P.S.
"Собственно файрволл там совсем не для этого - а для того, чтобы окончательно разделить ИСПДн, что называется, "наглушняк по ФСТЭК-овски"." по ФСТЭКовски наглушняк это только сертифицированный фаервол (МЭ) может сделать... как докажешь что это фаервол вообще, а не "сапер"?) сертификат соответствия нужен)
Гляньте здесь:
http://anvolkov.blogspot.com/2011/03/blog-post_22.html
http://anvolkov.blogspot.com/2011/03/blog-post_30.html
Поговорим там про официальные ответы, если еще будут вопросы :)
2 Алексей Волков
Алексей, Указанная на странице презентация (пост от 22.03.2011) про практику защиты ИСПДн - она еще актуальна или всвязи с последними изменениями нормативки (лицензирование и пр...), появились существенные изменения?
Имеется ли у Вас в наличие презентация "освеженная" под реалии сегодняшнего дня?
Черт!... А почему все участники дискуссии уже не работают по специальности? :)
Походу, я - тормоз.
Отправить комментарий