Безопасное администрирование

[Carder]

Привилегированный доступ позволяет администраторам выполнять свои обязанности, такие как создание и внесение изменений в ключевые серверы, сетевые устройства, рабочие станции пользователей и учетные записи пользователей. Привилегированный доступ или учетные данные часто рассматриваются как «ключи от королевства», поскольку они позволяют носителям иметь доступ и контроль над многими различными активами в сети. Эта публикация предоставляет руководство по реализации методов безопасного администрирования.

Введение​

Привилегированный доступ позволяет администраторам выполнять свои обязанности, такие как создание и внесение изменений в ключевые серверы, сетевые устройства, рабочие станции пользователей и учетные записи пользователей. Привилегированный доступ или учетные данные часто рассматриваются как «ключи от королевства», поскольку они позволяют носителям иметь доступ и контроль над многими различными активами в сети.
Привилегированный доступ часто является ключевой целью злоумышленника. Они могут использовать привилегированный доступ к:

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

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

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

Обоснование внедрения безопасного администрирования​

Цели злоумышленника, какими бы они ни были, намного легче достичь, если был обеспечен привилегированный доступ к сети или системе. Если злоумышленник не смог достичь своих целей с помощью доступа, предоставленного его первоначальной точкой опоры, получение привилегированного доступа к сети или системе может иметь чрезвычайно высокий приоритет. На это есть несколько причин:

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

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

Уроки группы реагирования на инциденты Австралийский центр кибербезопасности отреагировал на компрометацию правительственных сетей. В большинстве случаев злоумышленнику удавалось получить значительный привилегированный доступ, такой как доступ администратора домена, что позволяло ему более эффективно красть, изменять и повреждать данные; перемещаться по сети в боковом направлении, чтобы получить доступ к дополнительным ресурсам и оставаться незамеченными в сети дольше. Хорошо известный кибер-инцидент, когда привилегированные учетные записи были скомпрометированы и использовались для достижения целей злоумышленника, - это компрометация Sony Pictures Entertainment в 2014 году. Был похищен большой объем данных, включая интеллектуальную собственность, которые напрямую повлияли на деятельность компании. Кроме того, публично раскрывались конфиденциальные электронные письма, что серьезно подорвало репутацию компании. Наконец, вредоносное ПО было установлено на рабочих станциях, которые стерли жесткие диски, что привело к потере большого количества корпоративной информации. Помимо того, что это важный элемент управления безопасностью, реализация или отсутствие безопасной среды администрирования может существенно повлиять на эффективность расследования и действий по исправлению положения, выполняемых службами реагирования на инциденты в ответ на киберинцидент. Это особенно актуально, когда реагирующие на инциденты знают, что злоумышленник уже имеет привилегированный доступ, или подозревают, что это очень возможно из-за плохого состояния сетевой безопасности. Когда вы сталкиваетесь со значительным нарушением целостности сети, группа реагирования на инциденты рекомендует одним из распространенных действий по исправлению ситуации, когда создается безопасная среда администрирования. Из-за этого ресурсы, которые в противном случае были бы сосредоточены на действиях по исправлению, могут быть потрачены на создание безопасной среды администрирования. Это может привести к задержке полного восстановления сети, увеличивая последствия, связанные с компрометацией, поскольку у злоумышленника больше времени для распространения в сети, что приводит к краже конфиденциальной информации.

Элементы безопасного администрирования​

В таблице ниже представлены основные элементы управления безопасностью, лежащие в основе безопасного администрирования в организации. Каждый элемент управления безопасностью более подробно рассматривается в следующих разделах этого документа.
Хотя реализация каждого элемента управления безопасностью по отдельности может дать определенные преимущества (некоторые - больше, чем другие), эти элементы управления наиболее эффективны при реализации в виде пакета. Если весь пакет мер безопасности не может быть реализован за один шаг, предпочтительный порядок реализации - начать с верхней части таблицы и работать вниз.
Большинство из перечисленных ниже мер безопасности может быть достигнуто с помощью комбинации стандартных инструментов в современных операционных системах и логических изменений в организации и ее корпоративной сети.

Элемент	Описание
Управление привилегированным доступом	Контроль доступа к привилегированным учетным записям - это фундаментальный контроль безопасности, который защитит привилегированные учетные записи от неправомерного использования. Методология управления доступом будет охватывать концепции «минимальных привилегий» и «необходимость иметь», а также процессы и процедуры для управления учетными записями служб и перемещениями персонала.
Многофакторная аутентификация	Внедрение дополнительных факторов аутентификации помимо имен пользователей и парольных фраз, таких как физические токены или смарт-карты, может помочь защитить критически важные активы. Если злоумышленник скомпрометирует учетные данные для привилегированных учетных записей, поскольку все административные действия сначала должны будут проходить через какую-либо форму многофакторной аутентификации, последствия могут быть значительно уменьшены.
Привилегированные рабочие места	Использование известной безопасной среды для административных задач может привести к меньшему риску компрометации сети из-за реализации дополнительных мер безопасности.
Ведение журнала и аудит	Автоматическая генерация, сбор и анализ событий, связанных с безопасностью и администрированием, с рабочих станций, серверов, сетевых устройств и переходных блоков позволит обнаруживать компрометации и попытки взлома. Это позволит организациям быстрее реагировать, уменьшая последствия компромисса.
Сегментация и сегрегация сети	Сегментирование сети на логические зоны, такие как различные домены безопасности, и дальнейшее разделение этих логических сетей путем ограничения типов данных, которые передаются из одной зоны в другую, ограничивают горизонтальное перемещение. Это предотвратит получение злоумышленником доступа к дополнительным ресурсам.
Ящики для прыжков	Блок перехода - это защищенный сервер удаленного доступа, обычно использующий службы удаленных рабочих столов Microsoft или программное обеспечение Secure Shell (SSH). Он выступает в качестве отправной точки для администраторов, получающих доступ к критически важным системам, при этом все административные действия выполняются через окно перехода.

Управление привилегированным доступом​

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

• Убедитесь, что уникальные идентифицируемые учетные записи связаны с отдельными пользователями и они аутентифицируются каждый раз, когда в системе предоставляется привилегированный доступ. Это обеспечит подотчетность и ответственность за все действия.
• Ограничьте доступ для привилегированных учетных записей, предоставив администраторам стандартную учетную запись пользователя в дополнение к отдельным привилегированным и непривилегированным учетным записям администратора для административных целей. Раздельные учетные записи пользователя и администратора обеспечат логическое разделение административных и пользовательских задач, в то время как использование привилегированных и непривилегированных учетных записей администратора обеспечит еще один уровень абстракции для дальнейшей защиты учетных данных привилегированных учетных записей. Непривилегированная учетная запись администратора используется для управления удаленным доступом к коммутатору, корпоративным рабочим станциям и серверам, в то время как все фактические задачи администрирования выполняются с привилегированной учетной записью администратора с использованием runas, sudo и инструментов управления удаленным администрированием.
• Привилегированные учетные записи администратора не следует использовать для выполнения текущих задач в системе, в том числе с помощью «runas» или путем повышения привилегий с помощью контроля учетных записей Windows. Есть возможность извлекать хэши парольных фраз процессов, работающих с UAC и runas; однако после завершения процесса хэши очищаются. В случаях, когда службы или приложения требуют дополнительных привилегий на неопределенный срок или в течение длительного периода времени, вместо них следует использовать определенные учетные записи служб с минимально необходимыми разрешениями.
• Принудительное делегирование полномочий на основе ролей для привилегированных учетных записей администраторов уменьшит уязвимость учетной записи в случае взлома злоумышленником. По мере развития функциональных уровней Microsoft Active Directory были предоставлены встроенные группы администраторов с целью поощрения административного делегирования на основе ролей. Хотя эти группы представляют собой полезную отправную точку, вероятно, потребуется дальнейшая настройка на основе существующих организационных структур.
• Применение надежного управления парольной фразой для привилегированных и непривилегированных учетных записей администраторов снизит риск подбора парольной фразы и атак грубой силы на учетные записи администраторов.
• Отключение учетных записей локального администратора снизит риски, связанные с кражей учетных данных.
• Обеспечение использования безопасного рабочего стола Microsoft Window для ввода всех учетных данных привилегированных учетных записей, где это возможно. Это предотвратит регистрацию учетных данных регистраторами ключей, когда администраторы используют свою непривилегированную учетную запись администратора для повышения до своей привилегированной учетной записи администратора для выполнения административных действий. Этот параметр можно установить в групповой политике ( Контроль учетных записей пользователей: переключение на безопасный рабочий стол при запросе на повышение прав ).
• В последних выпусках Microsoft Windows рассмотрите возможность использования группы «Защищенные пользователи» для привилегированных учетных записей, если это поддерживается средой. Это обеспечит соблюдение протоколов строгой аутентификации и настроек Kerberos.
• Не разрешайте учетным записям служб быть членами каких-либо встроенных групп администраторов. Это снизит риски, связанные с кражей учетных данных. По возможности следует использовать управляемые учетные записи служб с делегированием определенных привилегий по мере необходимости.

Атаки Pass-the-Hash Pass-the-Hash (PtH) - это очень распространенный и эффективный метод, который злоумышленник может использовать для горизонтального перемещения внутри сети организации с конечной целью получения доступа к конфиденциальной информации и ресурсам. Один из распространенных способов выполнения PtH-атаки - раскрытие злоумышленником учетных данных для аутентификации учетных записей пользователей, которые ранее были аутентифицированы на скомпрометированной рабочей станции. Эти учетные данные затем передаются непосредственно по сети. Учетные данные обычно представляют собой хешированные пароли, хотя могут быть случаи, когда пароли в открытом виде или единый вход и многофакторные токены украдены. Среды, в которых учетные записи локальных администраторов используют один и тот же пароль во всей среде и где учетные записи администраторов домена и предприятия используются для регулярной поддержки рабочих станций, особенно уязвимы для этой атаки. Следуя предыдущим мерам безопасности для управления привилегированным доступом, использование PtH-атак становится намного сложнее. В частности, разделение привилегированных и непривилегированных учетных записей администратора и использование инструментов управления удаленным администрированием из окна перехода сокращают количество хэшей привилегированных учетных записей администратора, хранимых на рабочих станциях и серверах. Делегирование административных привилегий на основе ролей еще больше усиливает безопасность организации за счет максимального снижения последствий атак PtH за счет минимизации уязвимости сетей даже в случае взлома хэша привилегированной учетной записи. Другие меры безопасности в этом документе дополнительно смягчают атаки PtH и должны использоваться там, где это возможно.

Рекомендации при администрировании облачной среды​

При применении приведенного выше руководства к облачной среде нет особых проблем, которые следует учитывать.

Многофакторная аутентификация​

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

Привилегированная рабочая станция	Ящик для прыжков	Целевой актив
Преимущества Легкость интеграции с продуктом MFA. MFA также может охватывать вход на рабочую станцию.	Преимущества Легкость интеграции с продуктом MFA. MFA нужно развернуть только в централизованном месте.	Преимущества Процесс MFA происходит на целевом активе во время привилегированного действия.
Недостатки Повышенный риск компрометации рабочей станции и аутентификации, особенно если не используются выделенные привилегированные рабочие станции. Несколько мест развертывания Процесс MFA не выполняется для целевого актива. Процесс MFA не может выполняться временно рядом с привилегированным действием.	Недостатки Процесс MFA не выполняется для целевого актива. Процесс MFA не может выполняться временно рядом с привилегированным действием.	Недостатки Разные целевые активы на разных платформах должны поддерживать интеграцию с MFA. Несколько мест развертывания.
НЕ РЕКОМЕНДУЕТСЯ 1	РЕКОМЕНДУЕМЫЕ	РЕКОМЕНДУЕМЫЕ

1 Эта рекомендация относится к созданию безопасной среды администрирования. По-прежнему рекомендуется реализация многофакторной аутентификации на рабочей станции для обычных пользователей.

Рекомендации при администрировании облачной среды​

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

• Многие поставщики облачных услуг предлагают службу MFA, которую можно использовать для улучшения процесса аутентификации при доступе к облачным ресурсам, например при доступе к веб-консоли администратора или защите интерфейса прикладного программирования (API).
• Организации могут создать свой собственный выделенный сервер MFA в виртуальном частном облаке, чтобы улучшить процесс аутентификации на различных облачных серверах, размещенных в виртуальном частном облаке.
• Существующий локальный сервер MFA также может обеспечивать покрытие облачных активов.
• Процесс MFA может быть применен для локальных переходных блоков, которые затем используются для доступа к облачным сервисам. Это дает небольшую выгоду, если эти облачные сервисы могут администрироваться другими хостами, а не переходными блоками.
• Если доступ к виртуальному частному облаку осуществляется через виртуальную частную сеть (VPN), существующий локальный сервер MFA может расширить свое покрытие, включив в него облачные активы.

Привилегированные рабочие места​

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

Выделенные привилегированные рабочие станции​

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

Использование виртуализации для создания выделенных рабочих станций​

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

Конфигурация	Преимущества	Недостатки	Заметки
Удаленно виртуализированные привилегированные и пользовательские рабочие станции (предпочтительно)	Разделение рабочих станций, управляемых гипервизором и, возможно, физическим оборудованием. Улучшен контроль над рабочей станцией. Нет физического доступа к рабочим станциям, поэтому невозможно обойти меры безопасности.	Относительно сложно использовать. Возможно, более дорогой, поскольку также потребуется тонкий клиент. Доступность в случае отключения сервиса.	Для доступа к виртуализированным рабочим столам потребуется тонкий клиент. Привилегированная рабочая станция не должна быть постоянной.
Физическая привилегированная рабочая станция и виртуализированная пользовательская рабочая станция	Относительно сложно сбежать с виртуализированной пользовательской рабочей станции обратно на привилегированную.	Привилегированная рабочая станция должна быть постоянной.	Пользовательская рабочая станция должна быть удаленно виртуализирована, чтобы предотвратить доступ консоли к виртуальной машине.
Физическая рабочая станция пользователя и виртуализированная привилегированная рабочая станция (не рекомендуется)	Логическое разделение рабочих мест. Привилегированная рабочая станция может быть непостоянной.	Рабочую станцию можно использовать для перехода на привилегированную рабочую станцию с использованием функции передачи хеша, регистрации ключей или сохраненной парольной фразы.	Привилегированная рабочая станция должна быть удаленно виртуализирована, чтобы предотвратить доступ консоли к виртуальной машине.

Укрепление привилегированных рабочих станций​

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

• Убедитесь, что администраторы входят в систему с непривилегированной учетной записью администратора.
• Реализуйте правила брандмауэра на основе хоста, ограничивающие входящий и исходящий трафик только трафиком, необходимым для выполнения функций администрирования. Например, ограничьте исходящие службы удаленного доступа (например, службы удаленного рабочего стола (RDP), удаленное взаимодействие PowerShell и безопасную оболочку (SSH)) только полем перехода.
• Реализуйте строгую политику съемного хранилища. Это предотвратит использование вредоносными программами устройств хранения для обхода других средств управления разделением.
• Внедрите полное шифрование диска для защиты целостности рабочих станций, а также конфиденциальности любой конфиденциальной информации.

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

Рекомендации при администрировании облачной среды​

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

• Можно использовать локальный сервер перехода, используемый исключительно для управления облачными активами. Это окно перехода будет иметь подключение к Интернету, но будет ограничено доступом только к доменам или IP-адресам, необходимым для доступа к необходимым облачным службам и другим критическим службам, таким как серверы исправлений.
• Облачную среду можно настроить для приема административного трафика только из диапазона общедоступных IP-адресов организации, чтобы предотвратить несанкционированный доступ.
• Выделенный физический канал может обеспечить дополнительную безопасность для управляющих подключений к облачным службам.
• В тех случаях, когда переходный блок невозможен и привилегированные рабочие станции должны подключаться напрямую к облачной инфраструктуре, ограничьте рабочие станции доступом только к доменам или IP-адресам, необходимым для доступа к необходимым облачным службам.
• Если единственная администрируемая облачная служба - это частная виртуальная сеть (например, виртуальное частное облако Amazon или виртуальная сеть Microsoft Azure), доступ к которой осуществляется через VPN, то организация должна определить, следует ли применять ограничения на подключение к Интернету. По-прежнему рекомендуется использовать локальный сервер перехода.

Ведение журнала и аудит​

Сбор и анализ журналов для целей аудита - ключевой элемент защиты своей сети организацией. Комплексный сбор журналов и план аудита - это ключевой метод обнаружения важных событий безопасности и административных событий, позволяющий обнаруживать кибер-вторжения и определять соответствующие действия по реагированию на инциденты.
При реализации безопасного подхода к администрированию с использованием окна перехода, ведение журнала и аудит становится проще, поскольку весь административный доступ должен проходить через окно перехода. Хотя окно перехода является наиболее очевидной целью для ведения журнала и аудита, регистрация и связанные с ним действия все же должны выполняться в безопасной среде администрирования и на серверах, чтобы гарантировать, что все ключевые события подвергаются соответствующему аудиту.
Все события журнала должны фиксироваться и храниться в централизованном хранилище с резервными копиями. Централизация журналов событий упрощает сопоставление и корреляцию журналов, что помогает выявлять подозрительные события или аномалии. Кроме того, следует позаботиться о том, чтобы обеспечить синхронизацию времени в среде (и, соответственно, в журналах), чтобы обеспечить надлежащий анализ журналов.

Рекомендации при администрировании облачной среды​

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

Сегментация и сегрегация сети​

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

• Создавайте зоны для логического разделения разных доменов безопасности. Примерами различных зон могут быть зона пользовательской рабочей станции, привилегированная зона рабочей станции и зона активов.
• Ограничьте потоки трафика между зонами. Особенно для более чувствительных доменов безопасности, таких как привилегированная зона рабочей станции и зона активов, а также для чувствительных типов трафика управления, таких как RDP и SSH.
• Управляющий трафик должен проходить только между переходными блоками и управляемыми активами. Когда реализованы блоки перехода, единственными активами, которые должны иметь возможность управлять управляемыми активами, являются блоки перехода.

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

Разрешенный трафик​

Источник	Пункт назначения	Тип трафика
Привилегированная рабочая станция	Прыжковая коробка	Управляющий трафик (например, RDP, SSH)
Прыжковая коробка	Управляемые активы	Управляющий трафик (например, RDP, SSH)
Рабочее место пользователя	Управляемые активы	Деловой трафик (например, Интернет, почта, бизнес-приложения, порталы приложений, Active Directory)

Заблокированный трафик​

Источник	Пункт назначения	Тип трафика	Объяснение
Рабочее место пользователя	Управляемые активы	Управляющий трафик (например, RDP, SSH)	Рабочие станции пользователей не должны выполнять административные действия.
Рабочее место пользователя	Прыжковая коробка	Любой тип трафика	Рабочие станции пользователей не должны взаимодействовать с активами ИТ-администрирования.
Рабочее место пользователя	Привилегированная рабочая станция	Любой тип трафика	Рабочие станции пользователей не должны взаимодействовать с активами ИТ-администрирования.
Привилегированная рабочая станция	Управляемые активы	Любой тип трафика	Привилегированные действия следует выполнять через окно перехода.

Рекомендации при администрировании облачной среды​

Перечисленные выше меры безопасности могут применяться для администрирования сети на основе инфраструктуры как услуги (IaaS), особенно если также реализовано виртуальное частное облако.
В зависимости от функциональности предложения «Программное обеспечение как услуга» (SaaS) или «Платформа как услуга» (PaaS) может оказаться невозможным или непрактичным реализовать некоторые из перечисленных выше мер безопасности. Например, организации могут быть ограничены только контролем IP-адресов, с которых можно управлять облачным активом.

Ящики для прыжков​

Панель перехода может улучшить безопасную среду администрирования, обеспечивая три основных преимущества:

• Единая точка отправления для административных подключений. Поле перехода или определенная зона окна перехода обеспечивает единую точку отправления для административных соединений, таких как RDP или SSH, предназначенных для критически важных ресурсов. Это может помочь уменьшить административные накладные расходы и техническую сложность, тем самым уменьшая вероятность ошибок конфигурации.
• Более легкое обнаружение аномального или подозрительного поведения. Если были настроены окно перехода и зона администрирования, может быть проще определить аномальное поведение. Например, обычные пользователи и рабочие станции не должны администрировать важные серверы и приложения. Таким образом, попытки подключения RDP, исходящие из зоны пользовательской рабочей станции, предназначенные для зоны активов или блока перехода, будут подозрительными.
• Обеспечивает эффективное и простое развертывание многофакторной аутентификации. Теперь, когда все административные действия выполняются через окно перехода, может быть проще развернуть многофакторную аутентификацию, централизовав ее в поле перехода. Без блока перехода может быть труднее гарантировать, что все активы могут поддерживать многофакторную реализацию, используемую организацией.

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

• Внедрите надежную аутентификацию устройства или компьютера в дополнение к аутентификации пользователя, чтобы гарантировать, что только доверенные рабочие станции могут подключаться к блоку перехода. Например, выдача компьютерных сертификатов административным рабочим станциям и окно перехода в сочетании с параметрами политики IP-безопасности (IPSec), позволяющими удаленный сетевой доступ к окну перехода только для рабочих станций с доверенными сертификатами.
• Запретить прямой доступ в Интернет к окну перехода и обратно.
• Разрешить доступ к окну перехода только из безопасной среды администрирования. Заблокируйте трафик из всех других источников, чтобы защитить поле перехода от злоумышленника, который уже присутствует в сети.
• Запретить привилегированным учетным записям удаленный вход в окно перехода. Администраторы должны подключиться к окну перехода с непривилегированной учетной записью администратора, а затем при необходимости повысить свои привилегии.
• Выполняйте тщательный аудит с автоматическим анализом всех действий, выполняемых в окне перехода, включая вход в систему, выход из системы, выполнение программы, исходящие соединения и неудачные попытки входа в систему.
• Внедрить систему предотвращения и обнаружения вторжений (HIPS / HIDS) на основе хоста для выявления и предотвращения вредоносных и подозрительных действий.
• Изучите сбои системы, необычную активность и необычный сетевой трафик в качестве приоритета, чтобы определить, являются ли они индикаторами взлома.

На приведенной ниже диаграмме показан процесс администрирования с использованием окна перехода.

Рекомендации при администрировании облачной среды​

Блоки переходов могут быть реализованы различными способами при администрировании облачной среды. Ключевым моментом будет тип администрируемой облачной службы.

• Программное обеспечение как сервис. Поскольку облачное окно перехода, вероятно, невозможно с предложением SaaS, можно использовать локальное облачное окно перехода. Такой переходник следует использовать только для администрирования облачных сервисов, а не локальных ресурсов, поскольку он, вероятно, должен иметь возможность подключаться к Интернету.
• Платформа как услуга. PaaS будет использовать тот же подход, что и SaaS, поскольку организации, скорее всего, не смогут создать облачную платформу для перехода.
• Инфраструктура как услуга. В дополнение к подходу с локальной переходной рамкой, описанному для предложений SaaS и PaaS, для услуг IaaS можно использовать облачный подход с переходной рамкой. В этом сценарии облачный сервер используется в качестве выделенного блока перехода. Администраторы сначала подключались к облачному блоку перехода, а затем использовали его для администрирования других облачных серверов.