Аудит эко-системы HADOOP

[WhiteS404]

Привет, коллеги!
Есть задача провести аудит эко-системы HADOOP.
Опыта исследования данной системы нет.
Объекты аудита:
HDFS, HBASE, Map Reduse, YARN, Hive, Hue, Pig, Mahout, Avro, Sqoop, Spark, Oozie, Chukwa, Flume, ZooKeeper, Kafka

Сейчас идеи на уровне:
1) Получить информацию о версионности компонентов, сравнить с актуальной.
Это позволит найти устаревшие уязвимые объекты.
2) Получить список пользователей и прав доступа.
Сверить с матрицей управления доступом, ролевой моделью.
Здесь было бы неплохо, если подскажите, как этот список получить.

Посоветуете как составить план проверки, что можно ещё посмотреть, возможно направите как посмотреть?
Буду рад любой помощи.

 

[Сергей Сталь]

Как и любой аудит нужно начинать с начала
Кроме всего перечисленного тобой обрати особое внимание на следующее.
Кто администрирует систему, под какой учетной записью он это делает (У it специалиста который работает на серверах должно быть 3 учетных записи, 1 для работы на ПК, 2 для администрирования, 3 для работы на enteprise серверах). Как он хранит данные креденшелы в блокнотике, а блокнотик на столе под пивной кружкой. Как часто пароли меняются, не исключено что стоит галка в AD не менять пароль и данный пароль знают все кроме менеджера по влажной и сухой уборке.

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

Очень не плохо запросить документацию у тех кто ее поддерживает, скорее всего получишь ответ "вся документация у меня в голове" в таком случае лучше брать данного человека за половой орган плоскогубцами и по пути выкручивая по часовой стрелке, а потом против часовой в присутствии руководителя обсудить сроки предоставления всей необходимой информации в электронном виде которая перейдет в документ. Сроки закладывай в 3-4 раза меньше чем они просят, они будут плакать что у них нет времени, ползать на коленях по потолку, но ты на это не ведись ставь сроки в 1 неделю, так пиная в течении месяца получишь рыбу документа. К чему данные извращения в любой момент данный специалист может уволиться и его товарищ следом, а компания получит глобальную боль. Под этот случай я бы еще тебе посоветовал сделать 3+ мертвых флешки где на случай неожиданного увольнения, смерти, дождя из лягушек будут храниться в зашифрованном виде вся документация по администрированию оборудования в компании и креденшелы. Кто то скажет избыточно, но в одной компании где я работал ключевой безопастник лег спать и не проснулся, жаль но компания столкнулась с кучей проблем которые разгребала еще 2 года.

В общем что бы не разводить разговоры читать статьи до полного понимания как проводить аудит

Ссылка скрыта от гостей

и

Ссылка скрыта от гостей

. Если возникнут вопросы пиши попробую помочь

 

[WhiteS404]

@Сергей Сталь благодарю за столь развернутый ответ с кейсами из практики!

 

[Сергей Сталь]

@Сергей Сталь благодарю за столь развернутый ответ с кейсами из практики!

Не за что. Спокойного и плодотворного тебе аудита

 

[Pernat1y]

Ещё желательно узнать, куда идут логи, смотрит-ли их кто вообще и есть-ли у них SIEM.

 

[Сергей Сталь]

Ещё желательно узнать, куда идут логи, смотрит-ли их кто вообще и есть-ли у них SIEM.

отличная идея про логи, про слона то я совсем забыл. С SIEM это отдельная очень большая боль, купить дороха, а поддерживать еще дороже. Про open soure решения сказать не могу не пробовал