Я когда-то шутила, что не имею разрешения на свою работу, но эта шутка была недалека от правды. Я работала разработчиком в строго регулируемой энергетической отрасли. Системы, с которыми работал мой код, обрабатывали миллиарды долларов в месяц.
«У нас серьезная проблема в производстве. Можете посмотреть, что не так?» Я слышала эту фразу каждые несколько месяцев и пожимала плечами, отвечая: «Вы можете воспроизвести транзакцию, вызывающую проблемы в нашей тестовой среде? У меня нет доступа, необходимого для отладки в производственной среде».
В то время я категорически не соглашалась с таким жестким контролем, поскольку чувствовала себя бессильной решить стоящие передо мной проблемы, но со временем я начала понимать логику такого подхода. Когда на кону стоят такие большие деньги, уменьшение даже малейшего риска любой ценой – даже если эти критические минуты стоят компании бесчисленные суммы – вполне логично с точки зрения бизнеса. Стоимость потенциальной неудачи превышала стоимость задержки.
… мы стремимся создать тот беспроблемный опыт, к которому так стремятся разработчики…
Однако я мечтала о мире, где не приходилось бы жертвовать производительностью ради безопасности. Delinea стремится создать тот беспроблемный опыт, к которому так стремятся разработчики, одновременно обеспечивая безопасность их идентичностей, что позволяет бизнесу инновационно развиваться и преуспевать.
В этом блоге вы узнаете, как защитить и управлять идентификационными данными разработчиков – людей, ответственных за разработку. В рамках сотрудничества с разработчиками в области безопасности также следует учесть бесчеловечные, машинные идентичности, которые разработчики могут создавать и использовать в своей работе.
Почему идентификационные данные разработчиков так рискованны?
Идентификационные данные разработчиков — это идентичность людей, обычно имеющих особые привилегии. Разработчики играют решающую роль в управлении и усовершенствовании критически важных систем и инфраструктуры, что делает их привлекательной мишенью для злоумышленников.
Среди четырех типов идентичностей в вашей поверхности атаки на идентичность идентичности разработчиков наиболее сложны, поскольку они имеют общие характеристики с другими тремя типами. Как и ИТ-администраторы, у них высокий уровень привилегий и технических навыков. Как и идентичность сотрудников, их производительность очень ценится, а дистанционная работа и привлечение третьих сторон являются распространенной практикой. Добавьте к этому тот факт, что разработчики имеют доступ к машинным идентичностям и часто их создают.
Это мощная комбинация факторов, которая должна поставить идентичность разработчиков на первое место в вашем списке приоритетов.
Идентификационные данные разработчиков трудно защитить по нескольким причинам:
- Разработчики сосредоточиваются на эффективности, чтобы быстро выпустить код и запустить программное обеспечение, которое часто имеет приоритет над безопасностью. Они не хотят ждать утверждения, чтобы получить повышенные привилегии. Они предпочитают иметь постоянные привилегии, чтобы работать в удобное для них время.
- Как высококвалифицированные технические эксперты, разработчики могут быть независимыми; часто они используют программы, которые могут быть неизвестны центральному ИТ-отделу, или находят обходные пути для установленных процессов безопасности.
- Кроме внутренних команд штатных сотрудников разработка часто передается на аутсорсинг третьим сторонам, особенно в периоды интенсивного производства или реализации новых инициатив. Эти команды получают удаленный доступ к критически важным системам и конфиденциальным данным. Обычно они работают в группах, что может привести к совместному использованию аккаунтов или привилегированных аккаунтов.
- Разработчики имеют доступ к конфиденциальным данным, часто защищенным персональным данным и данным клиентам. Они работают не только в производственных средах, но и в средах разработки и тестирования. Кроме того, разработчики также используют сторонние репозитории, такие как GitHub, где часто можно забыть учетные данные.
Чтобы получить полное представление о рисках и устранить пробелы, руководители служб безопасности должны учитывать особые потребности разработчиков, интегрируя это сообщество в централизованно управляемые процессы.
Как защитить идентификационные данные разработчиков?
1. Выявление и инвентаризация
Благодаря непрерывному обнаружению, встроенному в программу защиты идентификационных данных, вы можете находить и классифицировать все привилегированные аккаунты и связанные с ними секретные данные, разрешения и правила MFA во всех локальных, облачных и программных средах.
Это гарантирует, что все удостоверения разработчиков, работающих в вашей расширенной ИТ-среде, учитываются, что уменьшает риск появления неуправляемых или заброшенных аккаунтов, которые могут быть использованы злоумышленниками.
Поскольку создаются новые идентификационные данные и учетные записи, а разрешения часто изменяются, постоянное обнаружение гарантирует, что у вас всегда есть новейшая информация и статус.
2. Защищенные учетные данные
Централизованное хранение и ротация учетных данных позволяют избежать использования статических секретов, используемых идентификаторами людей и машин. Разработчики, включая удаленных работников и сторонних лиц, должны иметь возможность легко использовать то же зашифрованное хранилище корпоративного уровня, что и остальные сотрудники предприятия, для динамического обновления паролей, устраняя типичные уязвимости, такие как статические и общие учетные данные.
Убедитесь, что вы можете связать права доступа и поведение с уникальными идентификаторами разработчиков, а не с общими привилегированными учетными записями.
Централизованные корпоративные хранилища также поддерживают рабочие процессы разработчиков, сохраняя и управляя учетными данными, используемыми служебными учетными записями, идентификаторами машин и искусственным интеллектом включая ключи SSH, токены и сертификаты.
3. Привилегированный безопасный доступ
Обеспечьте аутентификацию и авторизацию всех коммуникаций между разработчиками и машинами, а также между машинами с помощью детального контроля доступа, позволяющего осуществлять только легитимные взаимодействия.
Контекстно-зависимая многофакторная аутентификация (MFA) является важным средством безопасности для защиты идентичности разработчиков. Хотя MFA обеспечивает дополнительную защиту идентичности от целенаправленных атак, разработчики могут ощущать усталость от MFA – так же, как и все другие сотрудники вашей организации! Благодаря контекстной MFA вы можете выбирать, когда добавлять уровни защиты для систем или действий с высоким уровнем риска.
Привилегированный безопасный доступ – это не подход, который можно настроить один раз и забыть, особенно, если речь идет об идентификации разработчиков. Разработчики могут часто изменять проекты, требующие от них доступа к разным системам и данным. Такие условия делают статичные политики доступа, даже политики на основе ролей недостаточными. В отличие от фиксированных ролей, интеллектуальная авторизация динамична и базируется на контексте, включая изменение моделей поведения и оценки рисков.
4. Принятие принципа нулевых постоянных привилегий (ZSP)
Этот компонент безопасности идентичности гарантирует, что идентичности разработчиков работают со стандартным доступом, пока больше не понадобится. Вместо постоянных привилегий разработчикам предоставляются повышенные разрешения по принципу just-in-time, just-enough.
Благодаря внедрению нулевых постоянных привилегий (ZSP), лучшие практики безопасности соблюдаются без препятствования творческому и продуктивному процессу разработчиков.
Даже если идентичность разработчика будет скомпрометирована, ZSP сводит к минимуму радиус поражения и последствия, поскольку повышение привилегий и боковые перемещения ограничены.
5. Анализ состояния идентификации и угроз
В качестве превентивных мер контроля анализ состояния идентификации и угроз помогает выявлять распространенные ошибки настройки идентификации, такие как отсутствие MFA, и понимать связанные с ними риски.
Кроме того, аудит и мониторинг идентификационных данных, доступа и поведения разработчиков создают систему раннего предупреждения, которая дает вам время для принятия мер до того, как небольшая проблема превратится в катастрофу.
Получив базовые данные о типичном поведении разработчиков, вы сможете обнаруживать признаки потенциального нарушения безопасности или внутренней угрозы, например доступ разработчика к конфиденциальным данным в необычное время или создание им аккаунта со скрытым доступом.
Обнаружение угроз может даже сообщить вам, если атака MFA-бомбардировки посылает запросы друг за другом одному из ваших разработчиков. Тогда вы сможете вмешаться, прежде чем они случайно примут запрос и откроют дверь для атаки.
Вы можете сообщить об этом своей команде безопасности, чтобы она могла проверить сигналы об угрозах в соответствующем контексте, или даже включить автоматические действия, такие как применение дополнительных уровней многофакторной аутентификации (MFA) или полная отмена привилегированного доступа для идентификатораа разработчика.
6. Управление жизненным циклом идентификационных данных
Ручная предоставление, отмена доступа и постоянное управление идентификационными данными разработчиков являются трудоемким процессом, сопровождающимся риском человеческих ошибок.
Автоматизация упрощает процессы управления идентификационными данными разработчиков, такие как утверждение принятие, перевод и увольнение сотрудников (JML) и проверка доступа. Это уменьшает административные расходы и обеспечивает соблюдение политики безопасности и нормативных требований.
Кроме того, вы можете автоматизировать рабочие процессы, связанные с разработчиками, включая такие процессы, как предоставление и отмена доступа к аккаунтам, ввод секретных данных и управление изменениями, такими как инфраструктура как код.
Защита личностей разработчиков с помощью платформы Delinea
Платформа Delinea обеспечивает бесперебойную централизованную авторизацию для управления доступом разработчиков посредством интеллектуальных средств контроля на основе политик.
Вместо разрозненных решений, управляемых различными командами и разрозненными данными, вы можете защитить идентификационные данные разработчиков и управлять их доступом с помощью той же платформы, которая защищает и идентификационные данные работников, ИТ-администраторов, машин и ИИ.
Это означает, что вы можете получить полный обзор всех идентичностей, действующих в вашей среде, и целостное представление о рисках безопасности идентичностей.
Источник: Securing developer identities: A frictionless experience
