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

Может ли сущность существовать, не будучи упомянутой другой сущностью? Как мы можем это определить?

Это может показаться немного философским для статьи о безопасности, но это важный момент, который следует иметь в виду, когда речь заходит о неличностных сущностях. Более правильным вопросом в области безопасности на самом деле было бы: “Следует ли сущности существовать, если с ней нельзя взаимодействовать?” Мы можем не найти ответ на этот первоначальный вопрос, так как доказать природу реальности немного выходит за рамки компьютерных наук. Тем не менее, многие усердно работают над созданием инструментов управления НЛС для определения того, существует ли машинальная сущность, почему она существует и следует ли она существовать. 

Будущее устранения хаоса в области секретов заключается в понимании жизненных циклов и взаимосвязей нечеловеческих сущностей, которые зависят от секретов. Но почему сейчас? Давайте отойдем назад и переоценим некоторые из наших предположений о НЛС и их существовании.

Что такое Неличностные Сущности?

Прежде чем продолжить, давайте определим НЛС в контексте данного разговора.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

Это может быть под Kubernetes, который должен взаимодействовать с источником данных и отправлять обработанные данные в систему отчетности. Это может быть (Интернет вещей) (IoT) сенсор, передающий данные на центральный сервер. Это может быть чат-бот на основе Slack. Если после начального создания сущности не требуется прямого взаимодействия с человеком для выполнения работы, то мы должны считать эту сущность “неличностной”.

Единственное, что объединяет все эти примеры, – это взаимодействие с другой системой. Если мы хотим, чтобы они общались с целым миром, это легко сделать, просто указав на другие нечеловеческие сущности и программно описав, как они должны взаимодействовать. Однако, скорее всего, мы хотим, чтобы эти системы обменивались данными безопасно, авторизуя только определенные сущности в определенных обстоятельствах. Это привело к развитию секретов для управления доступом, от простых пар логин/пароль до ключей API и сертификатов.

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

Все NHIs подключаются к другим системам

Можно ли создать автономное приложение, которое не принимает входные данные, не генерирует выходные данные и не имеет адресного интерфейса? Существует ли такое приложение вне мысленного эксперимента? Хотя это интересно обсуждать, реальность заключается в том, что все NHIs, о которых мы заботимся, существуют для общения с другими сущностями.

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

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

Все защищенные NHI должны иметь секрет

Для установления доверенного общения между любыми двумя NHI должен существовать уникальный секрет, такой как ключ API, токен или сертификат, для аутентификации сущностей. Мы можем использовать секрет для подтверждения идентификации NHI и отображения его в экосистеме. Вопрос заключается в том, где мы ищем эти секреты? 

В современном предприятии, особенно в крупных, по сути есть только два места, где может находиться секрет. Ваш первый вариант – наилучшая практика и самый безопасный вариант: система управления секретами, такая как Conjur от CyberArk, Vault от HashiCorp или AWS Secrets Manager. Другой вариант намного менее безопасен, но, к сожалению, слишком распространен: за пределами хранилища, в коде или конфигурации в открытом виде.

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

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

Все секреты НИО имеют историю происхождения

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

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

Это критическая деталь, которая, возможно, никогда не была должным образом зарегистрирована или задокументирована где-либо еще. Как только вы поймете, кто создал секрет для того, чтобы воспользоваться NHI, тогда вы действительно поймете начало нашего жизненного цикла NHI.

Все секреты NHI должны предоставлять определенный набор разрешений

При создании каждому секрету NHI должны быть предоставлены определенные разрешения. Область действия определяет, какие действия может выполнять личность и на каких системах. Это делает определение области действия и ее соблюдение ключевыми компонентами управления.

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

Кроме того, также беспокоит тот факт, что когда секрет становится известен или скомпрометирован, команда не может заменить его, пока они не поймут, как были настроены эти разрешения. Например, предположим, что вы знаете, что секрет миссионерского микросервиса был случайно опубликован в общедоступном репозитории GitHub. В таком случае, это только вопрос времени, прежде чем его обнаружат и начнут использовать внешние лица извне вашей организации. В нашем недавнем отчете “Голос Практика”, принимающие решения в области IT признали, что в среднем требовалось 27 дней для поворота этих критических секретов. Командам следует действовать в считанные секунды или минуты, а не дни.

Необходимы инструменты, предоставляющие дополнительный контекст о обнаруженных секретах, включая их роли и разрешения. Быстрое понимание того, какие активы подвергаются риску при утечке и какие потенциальные ущербы могут быть причинены злоумышленником, существенно помогает при реагировании на инцидент. Знание точно того, как его заменить из виде панели управления или вызова API может означать разницу между нарушением и разочарованным атакующим, который обнаружит, что его ключ недействителен.

Все секреты NHI нужно поворачивать

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

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

Но что насчёт секретов NHI, которые находятся за пределами этих хранилищ, или, возможно, того же секрета, который распределён по нескольким хранилищам? Хорошая платформа сканирования секретов должна иметь безупречную интеграцию с этими хранилищами, чтобы ваша команда могла более легко найти и безопасно хранить эти секреты в менеджере секретов и подготовить путь для автоматизированной смены. Ссылка на реализацию GitGuardian с CyberArk’s Conjur даёт более подробную информацию о том, как вы можете полностью автоматизировать весь процесс хранения и смены.

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

У всех NHIs будет конец жизни

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

Один ответ заключается в том, что он больше не должен существовать, когда NHI больше не подключается к другой активной системе. Это гарантирует, что злоумышленники не смогут использовать устаревшие секреты NHI для проникновения в вашу среду. Помните, что злоумышленникам не важно, как должен использоваться секрет; им важно только то, что они с ним могут сделать.

Анализируя все отношения, которые позволяют секреты NHI, вы можете определить, когда система больше не подключена к какой-либо другой идентичности. Как только нет больше способов для идентичности общаться, тогда она и ее секреты больше не должны существовать. Это также означает, что секрету больше не нужно храниться в вашем менеджере секретов, что дает вам еще одну вещь для хранения и управления.

Понимание мира вокруг ваших NHIs критично для безопасности.

В 2022 году исследование CyberArk показало, что на каждую человеческую идентичность в среде необходимо управлять как минимум 45 нечеловеческими идентичностями. Вероятно, сегодняшнее соотношение ближе к 1 к 100 и продолжает увеличиваться. Лучшее время для принятия мер по управлению вашими НЧИ и их жизненным циклом было много лет назад. Следующее лучшее время – прямо сейчас.

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

Несмотря на то, что количество машинных идентификаторов превышает число людей, нет никакой причины работать в одиночку, чтобы решить эту проблему; мы все в этом вместе.