Аудит и внедрение SOX / HIPAA / и т. Д., Лучшие практики для конфиденциальных данных - PullRequest
5 голосов
/ 24 ноября 2008

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

Допустим, у нас есть «школьная» база данных с «учителями», «классами», «учениками», нормализованными в таблице «многие ко многим». Что бы вы войти? Каждая вставка / обновление в «таблице оценок»? Только обновления (скажем, ребенок взламывает и хочет изменить оценки, это должно отправить красные флажки)? Это полностью зависит от того, насколько параноиком хочется быть? Есть ли лучшая практика?

Это то, что должно быть сделано в базе данных? (Триггер на каждом секретном SELECT, который вставляет строку в таблицу «аудита», регистрирующую каждый запрос?) Что должно регистрироваться? Есть ли в Oracle / DB2 автоматически встроенные функции, которые делают это для вас? Должна ли это быть логика на стороне приложения?

Если у кого-то есть официальная документация / книги о том, как обращаться с конфиденциальными данными (не совсем со спецификацией DoD «Trusted Computing», но с чем-то вроде этого: P), я был бы признателен. Извините, если этот вопрос ужасно расплывчатый. Я понимаю, что это варьируется от приложения к приложению. Я просто хочу услышать ваш подробный опыт работы с конфиденциальными данными.

Ответы [ 2 ]

4 голосов
/ 01 декабря 2008

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

Следующее, что нужно понять, это то, что вы хотите проверить. Например, в случае HIPAA и SOX вы, вероятно, смотрите на PII - Персональная идентификационная информация. Вспомните суету вокруг людей, получивших доступ к телефонным записям Обамы, или к различным медицинским записям знаменитостей, или ... Они были пойманы, потому что система проверила, кто читал эти записи, и сотрудник по анализу аудита (AAO) заметил, что к записям знаменитостей обращались которые не были специально уполномочены на это. Таким образом, эти системы должны регистрировать, кто обращается к каждой записи, и определять, когда у пользователя, который делает это, нет подлинной бизнес-причины для этого. В этих случаях кажется, что пользователи имели права на чтение записей, поэтому, если их обычные обязанности требовали, чтобы они просматривали записи, они могли это сделать. Но когда они не обязаны были это делать, они злоупотребляли своей властью и подвергались соответствующим санкциям (вплоть до потери рабочих мест из-за этого).

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

OTOH, вы, вероятно, хотите записать, кто обращается к записям в истории болезни (HIPAA) или кто изменяет данные в системах учета (SOX). Вам может понадобиться или не беспокоиться о том, кто читает учетные данные; многое из этого может быть решено с помощью основных разрешений (бухгалтерия имеет разрешение; ИТ-персонал - нет). Однако одитинг - это всегда дополнительная линия защиты.

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

3 голосов
/ 29 ноября 2008

Oracle имеет продукт под названием Oracle Audit Vault - у DB2, вероятно, есть эквивалент.

Вы должны начать с профилактики . Система не должна допускать недопустимых действий. Период. Если система допускает «сомнительные» действия, которые необходимо отслеживать, то есть «бизнес-логику», вы, вероятно, лучше реализуете, как и остальная часть вашей бизнес-логики.

Если вы хотите что-то сделать в своей базе данных, вы можете посмотреть доставку журналов (терминология может отличаться от RDBMS к RDBMS). По сути, любая операция DML записывается в файл. Вы можете использовать эту информацию для резервного копирования и восстановления на определенный момент времени, даже для репликации / HA / failover / etc. Если вы отправляете свои журналы в отдельную «доверенную» систему в режиме «только добавление» (т. Е. Процесс доставки журналов имеет права на создание новых файлов журналов, но не на изменение существующей информации), у вас уже есть примитивная функция аудита , Если вы делаете это безопасным способом (т. Е. Аутентификация, безотказность), вы, вероятно, даже достаточно близки к «соответствию»: -p

Конечно, отсеивание множества операторов INSERT / UPDATE / DELETE - не самый сложный способ работы.

...