Больше реестров, хороших и разных. Заметки безопасника

Больше реестров, хороших и разных. Заметки безопасника

В прошлых заметках мы поговорили о реестрах пользователей и хостов, а также некоторых других объектов. Сегодня хотелось бы закрыть тему с реестрами, поговорив о более диковинных из них. Начнём с тех, которые были лишь вскользь упомянуты ранее.

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

Следующий момент — это доступные из интернета ресурсы: межсетевые экраны, веб-порталы, API-шлюзы и так далее. Для каждого такого устройства хочется знать как минимум публичный IP-адрес и краткое описание предоставляемого сервиса. Неплохо также иметь сведения об операционной системе и ключевых её компонентах: это очень актуально в момент выхода очередного «зеродея».

Хорошо бы ясно понимать, куда поступает внешний трафик и через какие промежуточные точки он проходит. В большинстве случаев здесь используется технология NAT, когда публичный IP-адрес преобразуется во внутренний. Однако всё может быть сложнее: например, опубликованный в интернете портал компании может находиться под защитой анти-DDoS сервиса, когда трафик вначале поступает на внешние сервера этого сервиса — и лишь затем, после «очистки», попадает в нашу инфраструктуру. При этом оригинальный адрес клиента-источника запроса может быть скрыт.

Если не очень опытный сотрудник, увидев подозрительный запрос, решит заблокировать «вредоносный» IP-адрес, с которого этот запрос пришёл, это может сделать ресурс недоступным для всех внешних пользователей. Конечно, со временем такие подробности становятся известны всем безопасникам — однако очень часто они хранятся и передаются в формате «устных народных преданий». А хочется видеть больше структуры и организованности, которые спасают сотрудников от излишнего стресса, а компанию порой и от серьёзных убытков (вспомним февральскую историю, где сотрудники Cloudflare «удачно» заблокировали фишинговую ссылку, в результате чего почти на час перестали работать некоторые их сервисы).

В завершение цикла упомяну реестр информационных систем. Как показывает практика, бизнес периодически прибегает с вопросами «А хорошо ли защищены наши критичные бизнес-системы?» — и на этот случай хорошо бы заранее договориться, какие системы мы считаем критичными, а какие имеют более низкий приоритет. Для каждой критичной системы надо знать её бизнес-владельца, верховного администратора, а также список входящих в неё хостов.

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