Лучшие практики управления идентификацией и доступом для обеспечения безопасности ваших данных
Gartner определяет управление идентификацией и доступом (IAM) как «дисциплину безопасности, которая позволяет нужным людям получать доступ к нужным ресурсам в нужное время по правильным причинам» и предполагает, что «предприятия, которые разрабатывают зрелые возможности управления идентификацией и доступом, могут уменьшить свою идентификацию». расходы на управление и, что более важно, стать значительно более гибкими в поддержке новых бизнес-инициатив». Многие поставщики программного обеспечения и облачных сервисов предлагают различные готовые решения IAM, начиная от локальных продуктов и систем и заканчивая облачными продуктами, такими как те, что доступны в Microsoft Azure. Но, по сути, IAM заключается не в использовании продуктов или услуг поставщиков, а в соблюдении надлежащей гигиены безопасности. Почему это важно? И какие рекомендации следует соблюдать, если вы хотите внедрить какое-либо решение IAM для своего бизнеса? Чтобы получить некоторое представление об этих вопросах, я недавно поговорил с Джеффри Харрисом, инженером по информационным технологиям, который работал со всеми версиями Windows, начиная с Windows 3.1. Джеффри имеет более чем 30-летний опыт работы в области ИТ, и большая часть этого опыта связана с ИТ-безопасностью и управлением идентификацией и доступом. Для тех из вас, кто еще относительно плохо знаком с этой темой, приведенные ниже отредактированные ответы Джеффри на вопросы, которые я ему задавал, могут послужить своего рода учебником по управления идентификацией и доступом, а также по правильному внедрению и выполнению IAM.
Какие основные концепции лежат в основе управления идентификацией и доступом?
Начнем с некоторых определений. Я собираюсь в основном сосредоточиться на IAM в контексте крупных компаний (но с некоторыми рекомендациями для небольших компаний и поставщиков услуг) и на рабочей силе компании, а не на клиентах (поскольку IAM для клиентов развивается быстрее, чем IAM для рабочей силы).
Во-первых, — это данные, представляющие пользователя или актера. В бизнес-настройке он обычно включает имя пользователя, отдел, назначенный пользователю, код должности, назначенный пользователю, менеджер пользователя, дату начала и т. д. Личность может быть назначена человеку, кто-то, кто работает на организацию или от ее имени, например, подрядчик или поставщик, или лицо, не являющееся личностью (также известное как бот или учетная запись службы). Идентификатор, не являющийся личностью, обычно имеет дополнительный атрибут, один или несколько владельцев, которые несут ответственность за идентификатор. Удостоверения также можно назначать устройствам, но это сложная тема, поэтому мы не будем ее здесь обсуждать. Обратите внимание, что конкретный пользователь (физический или нефизический) должен иметь только одно удостоверение, но может иметь столько учетных записей (и разрешений, назначенных этим учетным записям), сколько необходимо. Если пользователи имеют более одного удостоверения, то эффективно управлять этими удостоверениями, учетными записями и правами, назначенными пользователю, будет сложно (или невозможно).
Далее, — это доступ, предоставляемый от имени удостоверения. Я говорю «от имени», потому что удостоверениям не предоставляются права напрямую. Они предоставляются учетным записям, связанным с удостоверением, а сами учетные записи могут считаться типом полномочий, поскольку учетная запись дает пользователю право доступа к одной или нескольким системам или ресурсам. Учетные записи и права могут быть назначены учетным записям, связанным с личными или неличными удостоверениями.
Если пользователи имеют более одного удостоверения, то эффективно управлять этими удостоверениями, учетными записями и правами, назначенными пользователю, будет сложно (или невозможно).
— это просто имя или метка, связанная с личностью или учетной записью, и обычно следует стандартному соглашению, например, номер сотрудника, инициалы фамилии, адрес электронной почты и т. д.
— это механизм проверки того, что пользователь, утверждающий личность, является тем, за кого он себя выдает. Наиболее распространенными аутентификаторами являются пароли, но аутентификатор также может быть цифровым сертификатом, физическим устройством (например, пропускной картой) или логическим устройством (например, одноразовым приложением для генерации кода на смартфоне) или их комбинацией. типы. У учетных записей обычно есть аутентификаторы; личности никогда не имеют аутентификаторов.
представляют собой комбинацию идентификатора учетной записи и аутентификатора.
И, наконец, — это любое право, которое дает пользователю возможность изменять, обходить или отключать элементы управления безопасностью. Например, любой, у кого есть учетная запись администратора домена в домене Windows, имеет привилегированный доступ, поскольку пользователь может добавлять/удалять учетные записи (обычно это не возможность пользователя), разрешать/запрещать доступ для пользователей, изменять политики аудита и удалять данные аудита (вручную). удаление данных аудита почти всегда является нарушением политики в большинстве организаций).
Почему хороший IAM так важен для компаний в наши дни?
Target, Home Depot, Yahoo: это были одни из крупнейших утечек данных за все время, и у всех у них есть одна общая черта — украденные учетные данные! Но хотя украденные учетные данные являются причастными ко многим утечкам данных, это не единственная проблема. Учетные данные могут и использовались не по назначению (неправомерно переданы) для утечек данных, а также использовались уволенными или недовольными сотрудниками для создания утечек данных или мести работодателям. И даже когда утечки данных не достигают уровня событий Target или Yahoo, IAM важен для специалистов по безопасности и поставщиков услуг на всех уровнях. Во-первых, утечка данных может быть вызвана украденными или неправильным использованием учетных данных и привести к финансовому или репутационному ущербу для компаний, которым мы можем предоставлять услуги (будь то в качестве сотрудников или поставщиков услуг), как указано в ссылке выше. Во-вторых, они могут привести к потере работы специалистами по безопасности (для сотрудников) или ответственности или просто к потере бизнеса (для поставщиков услуг), если мы небрежно относимся к управлению данными IAM. Согласно одному опросу, 74 процента утечек данных связаны с неправомерным использованием привилегированного доступа. Некоторые организации и специалисты-практики считают управление идентификацией и доступом новой плоскостью управления, особенно для облачных сред, поскольку для подключения к большинству систем требуются определенные учетные данные.
Каковы передовые методы управления идентификацией и доступом?
Во-первых, обеспечьте строгую гигиену идентификации. У каждого пользователя должна быть идентификация в системе управления идентификацией безопасности (отдельно от любых систем управления персоналом), которая сопоставляет идентификационные данные из различных систем, являющихся источниками идентификационных данных. В большинстве организаций такими исходными системами являются системы управления персоналом или системы адаптации подрядчиков. Если имеется только одна система источника идентификационных данных (особенно в небольших компаниях), ее можно использовать в качестве системы управления идентификацией безопасности, но такой подход может ограничить возможность расширения возможностей системы для использования в более сложных целях управления идентификацией., или это может просто увеличить нагрузку на систему или увеличить ответственность сотрудников этих систем, которые могут разбираться в управлении данными в этих конкретных системах, но не в более широких функциях управления идентификацией безопасности. Для небольших организаций без отдельной системы регистрации можно использовать Active Directory в качестве исходной системы идентификации (в этом случае данные в домене Active Directory будут функционировать как данные идентификации и данные учетной записи). Однако опять же, этот подход не масштабируется, поскольку компании вырастают с 10 или 100 пользователей до тысяч пользователей. Для более крупных организаций с несколькими системами, предоставляющими источники достоверной информации о пользователях, важно объединить данные из таких систем о каждом отдельном пользователе в единую комплексную запись в системе управления идентификацией безопасности.
Учетные данные могут использоваться и использовались не по назначению (неправомерно переданы) с целью вызвать утечку данных, а также использоваться недовольными или уволенными сотрудниками для создания утечки данных или мести работодателям.
Во-вторых, отделите предоставление учетной записи и прав от управления идентификацией. Система управления идентификацией безопасности должна передавать идентификационные данные в системы обеспечения (т. е. системы, которые фактически управляют учетными записями и правами предоставления). Ни одна учетная запись не должна предоставляться без базовой идентификации, связанной с учетной записью. Причина этого в том, что когда пользователь, связанный с удостоверением, меняет работу или увольняется из компании, учетные записи и права могут быть отключены/удалены или может быть инициирована проверка доступа (подробнее об этом ниже) на основе изменений пользователя в источнике. системы. В небольших организациях, не имеющих системы управления идентификацией безопасности, по-прежнему должен существовать какой-то формальный процесс утверждения для назначения учетных записей и прав (например, владелец или генеральный менеджер отправляет сообщение электронной почты администратору учетных записей для создания учетной записи и предоставляет необходимые реквизиты для учетной записи). В более крупных организациях отделение управления идентификацией от подготовки повышает масштабируемость обеих систем и обеспечивает лучшее разделение обязанностей (администраторы системы идентификации не предоставляют учетные записи, а системные администраторы инициализации не могут создавать учетные записи и назначать права без соответствующей записи удостоверения, которую они не справиться).
В-третьих, настройте хранилище разрешений, которое идентифицирует все права во всех системах в организации, кому назначены эти права, и включает рейтинг риска и флаги привилегированного доступа для каждого права. Хотя в небольших организациях в этом может не быть необходимости, если все права назначаются в домене Active Directory или локально на небольшом количестве серверов или рабочих столов и, следовательно, могут быть легко собраны при необходимости, а количество разрешений ограничено. склад важен для более крупных организаций, ведь нельзя управлять тем, о чем не знаешь! Хранилище разрешений также можно использовать для проведения одноранговой аналитики для выявления необычных шаблонов назначений прав на основе прав, назначенных другим пользователям с аналогичными должностными обязанностями или назначенных пользователям из аналогичного или того же отдела. Хранилище разрешений также можно использовать для пометки разрешений для проверок привилегированного доступа (обсуждается ниже) и для присвоения пользователям оценок риска на основе оценок риска или флагов привилегированного доступа для назначенных пользователям прав. Каждое право должно иметь по крайней мере двух владельцев, уполномоченных и ответственных за утверждение (но не обязательно предоставление) назначения права другим пользователям, и права должны утверждаться только на основе рабочих функций и бизнес-потребностей.
В-четвертых, реализовать управление привилегированными пользователями. Любой доступ, считающийся привилегированным, должен быть назначен отдельной учетной записи в системе, для которой предоставляется доступ, и такие учетные записи должны быть назначены пользователю после соответствующего рассмотрения обязанностей пользователя и обоснования как привилегированной учетной записи, так и конкретного доступа ( эти учетные записи по-прежнему будут привязаны в системах подготовки к записи удостоверения пользователя). Любой определенный или предоставленный привилегированный доступ должен быть ограничен как по объему, так и по количеству пользователей, которым он назначается, и адаптирован к потребностям бизнеса. Например, если пользователь запрашивает администратора домена, но для выполнения своих обязанностей ему нужен только оператор учетной записи, дайте ему только оператора учетной записи (наименьшие права). В некоторых случаях доступ также может быть ограничен по времени (например, 30 дней на установку новой системы) или по объему (права администратора на серверы в определенной OU, а не на все серверы в компании). Система управления привилегированными пользователями управляет привилегированными учетными записями и паролями, сбрасывая пароли ежедневно или при оформлении заказа, и значительно снижает вероятность неправомерного использования таких учетных данных. Один из методов защиты групп администраторов Active Directory приведен в этой недавней статье TechGenix. Привилегированный доступ также можно усилить за счет реализации многофакторной аутентификации при доступе пользователей к конечным системам; использование многофакторной аутентификации для аутентификации в самой системе управления привилегированными пользователями является выигрышной комбинацией!
В-пятых, инвестируйте в системы и настройте их для использования решения с централизованной аутентификацией или единым входом. Сегодня большинство приложений могут использовать активный каталог для центральной аутентификации или стороннее решение единого входа. Использование централизованной проверки подлинности позволяет лучше управлять доступом, когда пользователи покидают компанию, и снижает количество случаев оставления потерянных локальных учетных записей (особенно привилегированных локальных учетных записей), которые могут быть украдены или использованы не по назначению.
В-шестых, проведите проверку аккаунта и доступа. Это можно делать периодически в небольших компаниях или на основе событий в крупных компаниях. Например, если пользователь меняет работу, инициируйте проверку доступа на основе изменений в коде должности пользователя или коде отдела. Проверка доступа также может основываться на риске или когда пользователи запрашивают определенные типы доступа (т. е. проводят проверку всех прав доступа пользователя, если пользователь запрашивает доступ администратора домена или если оценка риска пользователя достигает определенного уровня). Проверка доступа должна выполняться либо владельцами прав, либо текущим менеджером. В некоторых случаях, например при высоком риске или привилегированном доступе, имеет смысл проводить проверки обоим, причем обоим проверяющим необходимо одобрить сохранение права. Процесс проверки должен управляться автоматизированной системой проверки доступа или ИТ-персоналом, не связанным с управлением правами.
Доступ также должен быть удален во время или непосредственно перед уведомлением пользователей о том, что они были прекращены из-за увольнения или по уважительной причине.
В-седьмых, завершите деинициализацию! Учетные записи пользователей и права должны быть отозваны, когда пользователь покидает компанию или после проверки доступа, когда права не утверждены для сохранения. В более крупных организациях должен быть автоматизированный процесс для доступа всех пользователей. В небольших компаниях ИТ-отдел или поставщик услуг не должны быть последними, кого уведомляют об увольнении пользователей, смене работы или отдела. Когда пользователям больше не нужен доступ, основанный на текущих должностных обязанностях, критически важно удалить этот доступ, особенно если доступ дает привилегированный доступ или доступ для чтения конфиденциальных данных. Также рассмотрите возможность удаления привилегированного доступа и доступа с высоким риском для пользователей, когда они подают заявления об увольнении и уведомляют об уходе из компании. Доступ также должен быть удален во время или непосредственно перед уведомлением пользователей о том, что они были прекращены из-за увольнения или по уважительной причине. Доступ также должен быть удален, если пользователи его не используют, особенно привилегированный доступ, но для этого обычно требуется аудит и система для проверки действий пользователей и выявления таких неиспользуемых прав.
Следуя этим принципам и максимально автоматизируя процессы, вы можете помочь компании, в которой вы работаете или предоставляете ИТ-услуги, стать следующей целью или домашним складом или даже стать мишенью для возмездия со стороны недовольного сотрудника. И, наконец, обратите внимание, что, хотя я сосредоточил эти задачи в основном на личных учетных записях, те же самые методы применимы к неличным учетным записям и правам. В этом случае, например, проверки должны периодически проводиться либо владельцами аккаунта, либо менеджерами владельцев. Эти передовые методы также применимы к облачным средам, и из-за возможности быстро создавать новые облачные среды и заполнять их конфиденциальными или частными данными важно, чтобы все элементы управления, определенные для локального управления идентификацией и доступом, применялись к или адаптированы для облачных сред.