Аудит в CDP Private Cloud Base с использованием внешних систем

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

Любой, кто хранит информацию о клиентах, медицинскую, финансовую или конфиденциальную информацию, должен убедиться, что приняты необходимые меры для защиты этих данных, включая обнаружение и предотвращение непреднамеренного или злонамеренного доступа. Согласно исследованию Ponemon Institute, за два года в мире средний ущерб от инсайдерских угроз вырос на 31% и достиг 11,45 миллиона долларов, а частота инцидентов за тот же период увеличилась на 47%. В отчете за 2019 год указано, что компании больше всего беспокоятся о непреднамеренных нарушениях со стороны инсайдеров (71%), утечках данных из-за небрежности (65%) и злонамеренных действиях злоумышленников (60%), чем о взломанных учетных записях или машинах (9%).

Законодательные нормы GDPR, CCPA, HIPAA, PCI DSS и FIPS-200, требуют, чтобы организации принимали соответствующие меры для защиты конфиденциальной информации. Эти меры могут включать в себя три основных элемента:

• Шифрование данных — в «состоянии покоя» и при передаче по сети — гарантирует, что неаутентифицированные субъекты не могут получить доступ к данным.

• Контроль доступа (строгая аутентификация и авторизация) гарантирует, что пользователь – именно тот, кем он себя называет (аутентификация), и что он получит доступ только к тому, к чему ему разрешено (авторизация).

• Аудит и учет — знание того, кто к чему, и когда и кто обращался, и кто менял разрешения или настройки контроля доступа; потенциально предупреждает об утечках данных по мере их возникновения, а не постфактум.

В платформе Cloudera Data Platform с помощью Cloudera Shared Data Experience (SDX) обеспечивается сквозная безопасность. В CDP:

• Все «проводные» протоколы можно шифровать с использованием TLS или SASL.

• Все хранимые данные можно защитить с помощью прозрачного шифрования данных HDFS (частное облако) или шифрования хранилища объектов (публичное облако).

• Аутентификация пользователей как в публичном, так и в частном облаке выполняется через Kerberos/SPNEGO или SAML.

• С помощью Apache Ranger (как части SDX) весь доступ к данным реализуется на базе атрибутов или на основе ролей.

• Все средства управления доступом к данным проверяются с помощью Apache Ranger.

Защитный мониторинг

Эффективная программа защитного мониторинга (Protective Monitoring) может гарантировать видимость того, кто обращается или пытается получить доступ к данным: к каким данным и с каких устройств по всей своей ИТ-инфраструктуре. Это можно сделать с помощью следующих средств:

• Compliance and Reporting (проверка соответствия и отчетность) — постфактум сообщает о том, кто имеет доступ к определенным активам данных.

• Digital forensics and incident response (цифровая криминалистика и реагирование на инциденты) — реагирование на предписания регулирующих органов или уполномоченных по информации после выявления нарушений.

• Advanced threat detection (расширенное обнаружение угроз) — мониторинг событий в реальном времени для выявления изменений в поведении на уровне доступа пользователей, на уровне активов данных или коммуникаций между системами. Некоторые платформы SIEM, такие как Securonix, включают такие возможности.

Аудит в Cloudera Data Platform

Все компоненты доступа к данным в CDP отправляют события аудита в Apache Ranger, где они хранятся и доступны для поиска в течение настраиваемого периода хранения.

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

Примером удаленного сервера системного журнала, способного выполнять сложную логику фильтрации и маршрутизации, является кластер NiFi, на котором запущен процессор ListenSyslog.

Для этого настроим плагин Ranger для записи событий в log4j, а затем настроим log4j для каждой из служб, чтобы добавить файлы и приложения syslog.

HDFS

В ходе аудита HDFS проверяет все взаимодействия всех служб с файлами. Используя Cloudera Manager, мы установим следующие настройки:

HiveServer 2

Этот плагин будет проверять весь SQL, отправленный в HiveServer2. Конфигурация HiveServer2 использует синтаксис, отличный от синтаксиса других служб. Связано это с тем, что HiveServer2 использует Log4j2. С помощью Cloudera Manager установим следующие настройки в сервисе Hive on Tez:

Impala

Демоны Impala будут регистрировать все операторы Impala SQL. Это также настраивается через Cloudera Manager:

Solr

Сервер Solr будет регистрировать все запросы, отправленные в Solr API. Опять же, это должно быть настроено через Cloudera Manager:

Hue

Hue в настоящее время не интегрирован с Ranger, однако может отслеживать события в файле, включая события входа в систему и загрузку пользователями результатов запросов. Это можно включить через Cloudera Manager:

Пример вывода

После настройки этих параметров мы можем проверить, правильно ли отправляются события.

Следующие события были записаны сервером Rsyslog, запущенным на удаленном сервере с пользовательской конфигурацией:

HDFS

2021-05-04T03:25:36-07:00 host1.example.com HDFS: {«repoType»:1,»repo»:»cm_hdfs»,»reqUser»:»teststd»,»evtTime»:»2021-05-04 03:25:35.069″,«access»:»open»,«resource»:»/tstest/testfile2«,»resType»:»path»,«action»:»read»,«result»:1,»agent»:»hdfs»,»policy»:-1,»reason»:»/tstest/testfile2″,»enforcer»:»hadoop-acl»,»cliIP»:»172.27.172.2″,»reqData»:»open/CLI»,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»41a20548-c55d-4169-ac80-09c1cca8265e-0″,»seq_num»:1,»event_count»:1,»event_dur_ms»:1,»tags»:[],»additional_info»:»{\»remote-ip-address\»:172.27.172.2, \»forwarded-ip-addresses\»:[], \»accessTypes\»:[read]»,»cluster_name»:»CDP PvC Base Single-node Cluster»}

2021-05-04T03:29:27-07:00 host1.example.com HDFS: {«repoType»:1,»repo»:»cm_hdfs»,»reqUser»:»teststd»,»evtTime»:»2021-05-04 03:29:22.375″,«access»:»open»,«resource»:»/tstest/testfile3″,»resType»:»path»,«action»:»read»,«result»:0,»agent»:»hdfs»,»policy»:-1,»reason»:»/tstest/testfile3″,»enforcer»:»hadoop-acl»,»cliIP»:»172.27.172.2″,»reqData»:»open/CLI»,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»e6806644-1b66-4066-ae0d-7f9d0023fbbb-0″,»seq_num»:1,»event_count»:1,»event_dur_ms»:1,»tags»:[],»additional_info»:»{\»remote-ip-address\»:172.27.172.2, \»forwarded-ip-addresses\»:[], \»accessTypes\»:[read]»,»cluster_name»:»CDP PvC Base Single-node Cluster»}

В приведенном выше примере было отказано во втором доступе (результат: 0).

Hive

2021-05-04T03:35:25-07:00 host1.example.com Hive: {«repoType»:3,»repo»:»cm_hive»,»reqUser»:»admin»,»evtTime»:»2021-05-04 03:35:23.220″,«access»:»SELECT»,«resource»:»default/sample_07/description,salary«,»resType»:»@column»,»action»:»select»,»result»:1,»agent»:»hiveServer2″,»policy»:8,»enforcer»:»ranger-acl»,»sess»:»303bbfbe-3538-4ebe-ab48-c52c80f23a35″,»cliType»:»HIVESERVER2″,»cliIP»:»172.27.172.2″,»reqData»:»SELECT sample_07.description, sample_07.salary\r\nFROM\r\n  sample_07\r\nWHERE\r\n( sample_07.salary \u003e 100000)\r\nORDER BY sample_07.salary DESC\r\nLIMIT 1000″,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»b6903fd2-49bd-4c8e-bad6-667ae406f301-0″,»seq_num»:1,»event_count»:1,»event_dur_ms»:1,»tags»:[],»additional_info»:»{\»remote-ip-address\»:172.27.172.2, \»forwarded-ip-addresses\»:[]»,»cluster_name»:»CDP PvC Base Single-node Cluster»,»policy_version»:1}

Impala

2021-05-04T03:32:01-07:00 host1.example.com Impala: {«repoType»:3,»repo»:»cm_hive»,»reqUser»:»admin»,»evtTime»:»2021-05-04 03:31:54.666″,«access»:»select»,«resource»:»default/sample_07″,»resType»:»@table»,»action»:»select»,»result»:1,»agent»:»impala»,»policy»:8,»enforcer»:»ranger-acl»,»cliIP»:»::ffff:172.27.172.2″,«reqData»:»SELECT s07.description, s07.salary, s08.salary,\r   s08.salary — s07.salary\r FROM\r   sample_07 s07 JOIN sample_08 s08\r ON ( s07.code \u003d s08.code)\r WHERE\r  s07.salary \u003c s08.salary\r ORDER BY s08.salary-s07.salary DESC\r LIMIT 1000″,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»f995bc52-dbdf-4617-96f6-61a176f6a727-0″,»seq_num»:0,»event_count»:1,»event_dur_ms»:1,»tags»:[],»cluster_name»:»CDP PvC Base Single-node Cluster»,»policy_version»:1}

Solr

В аудите Solr по умолчанию проверяется только факт выполнения запроса:

{«repoType»:8,»repo»:»cm_solr»,»reqUser»:»admin»,»evtTime»:»2021-05-04 02:33:22.916″,«access»:»query»,«resource»:»twitter_demo»,»resType»:»collection»,»action»:»query»,»result»:1,»agent»:»solr»,»policy»:39,»enforcer»:»ranger-acl»,»cliIP»:»172.27.172.2″,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»951c7dea-8ae7-49a5-8539-8c993651f75c-0″,»seq_num»:1,»event_count»:2,»event_dur_ms»:199,»tags»:[],»cluster_name»:»CDP PvC Base Single-node Cluster»,»policy_version»:2}

Однако, если в Solr включена авторизация на уровне документа, мы также увидим текст запроса:

2021-05-04T06:23:00-07:00 host1.example.com Solr: {«repoType»:8,»repo»:»cm_solr»,»reqUser»:»admin»,»evtTime»:»2021-05-04 06:22:55.366″,«access»:»query»,«resource»:»testcollection»,»resType»:»collection»,»action»:»others»,»result»:0,»agent»:»solr»,»policy»:-1,»enforcer»:»ranger-acl»,»cliIP»:»172.27.172.2″,»reqData»:»{! q\u003dtext:mysearchstring doAs\u003dadmin df\u003d_text_ echoParams\u003dexplicit start\u003d0 rows\u003d100 wt\u003djson}»,»agentHost»:»host1.example.com»,»logType»:»RangerAudit»,»id»:»6b14c79f-e30d-4635-bd07-a5d116ee4d0f-0″,»seq_num»:1,»event_count»:1,»event_dur_ms»:1,»tags»:[],»cluster_name»:»CDP PvC Base Single-node Cluster»}

Hue

Эти строки записываются непосредственно из файла журнала аудита Hue.

{«username»: «admin», «impersonator»: «hue», «eventTime»: 1620124241293, «operationText»: «Successful login for user: admin», «service»: «hue», «url»: «/hue/accounts/login», «allowed»: true, «operation»: «USER_LOGIN», «ipAddress»: «10.96.85.63»}

{«username»: «admin», «impersonator»: «hue», «eventTime»: 1620131105118, «operationText»: «User admin downloaded results from query-impala-46 as xls», «service»: «notebook», «url»: «/notebook/download», «allowed»: true, «operation»: «DOWNLOAD», «ipAddress»: «10.96.85.63»}

Заключение  

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

Выше мы обсудили способы отправки событий аудита в CDP на внешнюю систему SIEM с использованием аудита на основе файлов и системного журнала.

Для получения дополнительной информации о настройке и использовании Apache Ranger ознакомьтесь с документацией по CDP.