ЗоПД, обезличивание и аутентификация

Как известно, закон строг, но справедлив. К ЗоПД можно отнести только первую часть известного высказывания. Похоже, создавался этот закон совершенно для иных целей. Но, как бы то ни было, выполнять его все же надо. Многие организации его не выполняют, надеясь на русский "авось", но это когда-нибудь может выйти боком.

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

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

Трудности тут связаны с тем, что обезличивать данные очень не удобно, и, чаще всего, невозможно. Что значит обезличить данные? Это значит убрать из персональных данных все сведения, по которым можно установить личность человека, к которым эти данные относятся. То есть сюда сразу автоматически попадают фамилия, имя и отчество, а также все федеральные идентификаторы (номер паспорта, СНИЛС и ИНН). Естественно, чаще всего из базы трудно убрать как минимум ФИО по тем или иным причинам, а также идентификаторы. Это может быть связано как с особенностью работы организации, так и с тем, что эти сведения по закону требуется передавать в гос. органы.

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

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

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

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

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

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

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

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

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

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

В принципе, так как по значению хэш-функции в данном ее применении не возможно предпринять каких-либо деструктивных действий, то особых требований к ее криптостойкости нет. Поэтому можно использовать как стандартные алгоритмы, такие как MD5, SHA-2 или ГОСТовской вариант. Недостаток таких функции состоит в их достаточно высокой вычислительной сложности, что не всегда удобно. Поэтому можно использовать и свои, более простые варианты хэш-функций.

С точки зрения ЗоПД использование значения функции свертки вполне легально, так как там не определены способы получения идентификатора для обезличивания данных.