IAM

IAM, или Identity and Access Management, — набор технологий и процессов для управления цифровыми идентификаторами пользователей, устройств и сервисов, а также их доступом к информационным системам.

IAM помогает ответить на два ключевых вопроса: кто пытается получить доступ и что этому субъекту разрешено делать.

В корпоративной инфраструктуре IAM используется для централизованного управления учетными записями, Authentication, ролями, группами, Single Sign-On, Multi-factor Authentication и жизненным циклом доступа сотрудников.

IAM связывает цифровую идентичность пользователя с правилами доступа к приложениям, данным и инфраструктуре.

Что такое IAM простыми словами

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

Без централизованного IAM администратор создает отдельный Account в каждом сервисе и вручную удаляет его после увольнения сотрудника.

С IAM процесс может выглядеть так:

Employee
↓
Corporate Identity
↓
IAM
↓
CRM / Email / ERP / Cloud

Сотрудник получает корпоративную Identity, а система автоматически определяет, к каким приложениям он имеет доступ.

Расшифровка IAM

IAM расшифровывается как Identity and Access Management — управление идентификацией и доступом.

Identity отвечает за представление пользователя или технического субъекта в системе, а Access Management — за правила предоставления доступа.

Основные задачи IAM

IAM используется для:

• создания и удаления Accounts;
• Authentication пользователей;
• Authorization действий;
• управления ролями и группами;
• Single Sign-On;
• Multi-factor Authentication;
• Provisioning и Deprovisioning;
• управления Service Accounts;
• аудита доступа;
• реализации Least Privilege.

Что такое Identity

Identity — цифровое представление пользователя, устройства или программы.

Она может содержать:

IAM использует эти атрибуты при принятии решений о доступе.

Identity и Account

Identity и Account не всегда означают одно и то же.

Один сотрудник может иметь единую корпоративную Identity, но несколько Accounts в разных системах.

Identity: Ivan Petrov
↓
CRM Account
Email Account
ERP Account
Cloud Account

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

Authentication

Authentication отвечает на вопрос: кто вы?

Пользователь должен подтвердить свою Identity.

Для этого могут использоваться:

• Password;
• одноразовый код;
• Authenticator Application;
• Hardware Token;
• Certificate;
• Biometric Factor.

Authorization

Authorization отвечает на другой вопрос: что вам разрешено делать после Authentication?

Например, сотрудник успешно вошел в CRM, но может только читать клиентов своего отдела.

Authentication и Authorization

Access Control

Access Control определяет, какие действия субъект может выполнять над конкретным Resource.

Например:

User: accountant-17
Resource: invoices
Permission: read, create
Permission denied: delete

Permission

Permission — отдельное разрешение на действие.

Примеры:

• Read;
• Write;
• Delete;
• Create;
• Approve;
• Administer.

В крупных системах выдавать Permissions каждому пользователю вручную неудобно, поэтому применяются Roles и Groups.

Role

Role объединяет набор разрешений, соответствующих определенной функции.

Например:

Role: Accountant
Permissions:
read invoices
create invoices
export reports

Новому бухгалтеру достаточно назначить одну Role вместо десятков отдельных Permissions.

RBAC

RBAC, или Role-Based Access Control, — модель управления доступом на основе ролей.

Пользователь получает Role, а Role содержит набор Permissions.

User → Role → Permissions

RBAC широко применяется в корпоративных системах благодаря понятной модели администрирования.

Проблема Role Explosion

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

Например:

Accountant Moscow
Accountant Berlin
Senior Accountant Moscow
Senior Accountant Berlin

Сотни подобных Roles усложняют управление IAM.

ABAC

ABAC, или Attribute-Based Access Control, принимает решение на основании атрибутов.

Условие может выглядеть концептуально так:

department = finance
AND country = Germany
AND device_compliant = true
→ allow

ABAC дает более гибкую модель, но сложнее в проектировании.

Policy-Based Access Control

Access Policy описывает условия доступа.

Например, финансовая система доступна только сотрудникам Finance Department с управляемого устройства и после MFA.

Least Privilege

Принцип Least Privilege означает, что пользователю предоставляют только минимальные права, необходимые для выполнения работы.

Бухгалтеру не нужен Administrator Access к серверу только потому, что он работает с приложением на этом сервере.

Почему избыточные права опасны

Если Account скомпрометирован, злоумышленник получает те же Permissions, что и пользователь.

Чем шире права, тем больше потенциальный ущерб.

Need to Know

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

Это дополняет принцип Least Privilege.

Жизненный цикл Identity

IAM должен управлять пользователем от приема на работу до увольнения.

Обычно выделяют этапы:

Joiner
↓
Mover
↓
Leaver

Joiner

При приеме нового сотрудника создается корпоративная Identity и назначается базовый набор доступа.

Например, Email, Messenger, Service Desk и приложения отдела.

Mover

Если сотрудник переходит в другой Department, старые права должны быть пересмотрены.

Иначе со временем человек накапливает доступ от нескольких предыдущих должностей.

Leaver

При увольнении Account необходимо своевременно отключить.

Также отзываются:

• Sessions;
• Tokens;
• VPN Access;
• Cloud Roles;
• Application Accounts;
• Certificates.

Deprovisioning

Deprovisioning — процесс удаления или отключения доступа.

Он критичен для безопасности.

Если пользователь удален только из HR-системы, но его VPN и Cloud Accounts продолжают работать, возникает Security Gap.

Provisioning

Provisioning — создание Accounts и выдача доступа в целевых системах.

IAM может автоматизировать процесс на основании должности, отдела и других атрибутов.

Automatic Provisioning

Например, HR создает запись нового сотрудника:

Name: Anna
Department: Sales
Role: Manager

IAM автоматически создает необходимые Accounts и добавляет пользователя в соответствующие Groups.

SCIM

SCIM используется для стандартизированного обмена информацией о пользователях и группах между Identity System и приложениями.

Он может автоматизировать создание, изменение и удаление Accounts в SaaS Services.

Directory Service

Directory Service хранит информацию об Identities и связанных объектах.

Типичные данные:

• Users;
• Groups;
• Computers;
• Attributes;
• Organizational Units.

IAM и Active Directory

Active Directory является одной из распространенных Directory Services в корпоративной Windows-инфраструктуре.

Она может хранить Users, Groups и Computers и участвовать в Authentication и Authorization.

IAM является более широким понятием и может объединять локальные Directory, Cloud и SaaS Systems.

LDAP

LDAP — протокол доступа к Directory Services.

Приложение может использовать LDAP для поиска Users и Groups или выполнения Authentication согласно архитектуре системы.

LDAP не является полной заменой IAM.

Single Sign-On

SSO, или Single Sign-On, позволяет пользователю пройти Authentication один раз и затем получить доступ к нескольким приложениям.

User
↓ login once
Identity Provider
↓
CRM
ERP
Wiki
Service Desk

Это уменьшает количество отдельных Passwords.

Преимущества SSO

SSO упрощает работу пользователей и позволяет централизовать Authentication Policy.

Например, организация может одновременно включить MFA для десятков приложений через один Identity Provider.

Риски SSO

Компрометация основной корпоративной Identity становится особенно опасной, поскольку она предоставляет доступ к множеству сервисов.

Поэтому SSO должен сочетаться с MFA, Conditional Access и Monitoring.

Identity Provider

Identity Provider, или IdP, выполняет Authentication и предоставляет приложениям информацию о пользователе.

Приложению не обязательно самостоятельно хранить Password каждого сотрудника.

Service Provider

Service Provider — приложение, которое доверяет результату Authentication от Identity Provider.

После успешного Login оно создает Session и применяет собственные Authorization Rules.

Federation

Identity Federation позволяет одной организации или системе доверять Authentication, выполненной другой Identity Platform.

Это особенно удобно для SaaS и взаимодействия между организациями.

SAML

SAML широко применяется для корпоративного Web SSO.

Identity Provider подтверждает Identity пользователя и передает Service Provider соответствующее утверждение.

OAuth

OAuth используется для делегирования доступа приложениям.

Например, пользователь разрешает сервису читать определенные данные без передачи ему своего основного Password.

OAuth прежде всего связан с Authorization, а не с классической пользовательской Authentication.

OpenID Connect

OpenID Connect добавляет Identity Layer поверх OAuth-подобной модели и широко используется для Authentication современных Web и Mobile Applications.

Приложение получает информацию о подтвержденной Identity пользователя.

Token

После Authentication система часто выдает Token.

Приложение использует его вместо постоянной передачи Password при каждом Request.

Access Token

Access Token предоставляет доступ к определенному Resource или API.

Он должен иметь ограниченный Scope и срок действия.

Refresh Token

Refresh Token используется для получения новых Access Tokens без повторного Login пользователя.

Из-за длительного срока жизни его необходимо особенно надежно защищать.

Token Revocation

Если Account скомпрометирован, одной смены Password может быть недостаточно.

Активные Tokens и Sessions следует отозвать согласно возможностям Identity Platform.

Session

После успешной Authentication приложение создает Session.

Она позволяет пользователю продолжать работу без повторного ввода Credentials для каждого действия.

Session Timeout

Слишком долгоживущая Session увеличивает риск использования украденного устройства или Token.

Слишком короткая ухудшает User Experience.

IAM Policy должна учитывать критичность приложения.

MFA

Multi-factor Authentication требует несколько независимых факторов подтверждения Identity.

Например:

Password
+
Authenticator confirmation

Кражи одного Password становится недостаточно для входа.

Факторы Authentication

Обычно используют категории:

• то, что пользователь знает;
• то, чем пользователь владеет;
• то, чем пользователь является.

Пример — Password, Hardware Token и Biometric Verification.

Почему два пароля не являются настоящей MFA

Два Password относятся к одному типу фактора — знанию.

Для MFA нужны независимые категории факторов.

Passwordless Authentication

Passwordless подход позволяет уменьшить зависимость от традиционных Passwords.

Пользователь может подтверждать Identity с помощью Cryptographic Key, Device и Biometric Verification.

Conditional Access

Conditional Access принимает решение на основании контекста.

Например:

User = Finance
Device = managed
Country = expected
MFA = passed
→ allow access

Если условия не выполнены, система может запросить дополнительную Authentication или заблокировать вход.

Контекст доступа

IAM может учитывать:

• User;
• Role;
• Device;
• IP Address;
• Location;
• Risk Score;
• Application;
• время доступа.

IAM и Zero Trust

Identity является одним из центральных элементов Zero Trust.

Пользователь не получает доверие только потому, что находится во внутренней сети.

Каждый Access Request оценивается по Identity и Context.

Device Identity

Доступ может зависеть не только от пользователя, но и от состояния устройства.

Например, CRM разрешается открывать только с корпоративного Notebook с включенным EDR и Disk Encryption.

Service Account

Service Account — техническая Identity, используемая приложением, сервером или автоматизацией.

Она не должна использоваться человеком для обычной работы.

Почему Service Accounts опасны

Технические Accounts часто существуют годами и могут иметь широкие Permissions.

Если Credentials не ротируются и никто не знает владельца Account, риск компрометации повышается.

Machine Identity

Не только люди нуждаются в Authentication.

Microservice должен подтвердить свою Identity перед обращением к другому Service или Database.

IAM для API

API может проверять Access Token и его Scope.

Например:

Token scope: orders.read
GET /orders → allow
DELETE /orders → deny

Так Authentication и Authorization применяются к Machine-to-Machine взаимодействию.

Client Credentials

В Server-to-Server интеграциях приложение может иметь собственные Credentials.

Такие Secrets необходимо хранить в Secret Manager и регулярно ротировать.

IAM и Secrets Management

IAM определяет Identity и права, а Secrets Management хранит Passwords, API Keys и другие чувствительные Credentials.

Эти области тесно связаны, но решают разные задачи.

IAM и PAM

PAM, или Privileged Access Management, специализируется на привилегированных Accounts и административном доступе.

IAM управляет доступом широкой группы пользователей, а PAM добавляет более строгий контроль Administrator и Root Credentials.

Privileged Account

Привилегированная учетная запись имеет расширенные возможности:

• создание Users;
• изменение Security Policy;
• доступ к критичным данным;
• управление Servers;
• назначение Roles.

Такие Accounts требуют дополнительного контроля.

Standing Privileges

Standing Privileges — постоянные административные права.

Если пользователь использует их только раз в месяц, разумнее выдавать доступ временно.

Just-in-Time Access

JIT Access предоставляет повышенные права только на ограниченный период.

User requests admin
↓ approval
Admin role for 1 hour
↓
automatic revoke

Так уменьшается время, в течение которого Account является высокопривилегированным.

Just Enough Access

JEA-подобный подход означает предоставление только конкретного набора административных действий вместо полного Administrator Role.

Это уменьшает потенциальный Blast Radius.

Separation of Duties

Разделение обязанностей не позволяет одному пользователю полностью контролировать критичный бизнес-процесс.

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

Segregation of Duties Conflict

IAM Governance может выявлять конфликтующие Roles.

Например, одному Account нежелательно одновременно иметь права создания поставщика и утверждения платежа этому поставщику.

Access Request

Сотрудник может запросить дополнительный доступ через Portal.

Workflow определяет, кто должен его согласовать.

User request
↓
Manager approval
↓
Resource owner approval
↓
Provision access

Access Review

Даже легитимно выданные права со временем могут стать ненужными.

Access Review позволяет владельцу системы периодически подтвердить или отозвать доступ пользователей.

Access Certification

Certification — формализованная проверка существующих Permissions.

Она особенно важна для Privileged и финансовых систем.

Orphan Account

Orphan Account — учетная запись, которая существует в приложении, но больше не связана с активным сотрудником или владельцем.

Такие Accounts являются серьезным риском.

Dormant Account

Dormant Account долго не используется, но остается активным.

IAM Monitoring должен выявлять подобные Accounts и инициировать Review.

Shared Account

Shared Account используется несколькими людьми.

Это усложняет Audit, потому что невозможно точно определить, кто выполнил действие.

По возможности следует использовать индивидуальные Identities.

IAM и аудит

IAM должен фиксировать важные события:

IAM и SIEM

IAM Events являются одним из наиболее важных источников для SIEM.

Security Team может обнаружить:

• Brute Force;
• Password Spraying;
• необычный Login;
• назначение Admin Role;
• отключение MFA;
• создание подозрительного Account.

IAM и SOC

SOC анализирует Identity Alerts и при подтвержденной компрометации может инициировать блокировку Account или отзыв Sessions.

Identity является важным элементом расследования современных атак.

IAM и XDR

XDR объединяет Identity Events с Endpoint, Email, Network и Cloud Telemetry.

Например:

Phishing email
↓
Credential theft
↓
Unusual login
↓
Cloud access

IAM предоставляет критичную часть такой цепочки.

Compromised Account

Если злоумышленник знает правильный Password, Firewall и приложение могут считать его обычным пользователем.

Поэтому IAM должен использовать MFA, Risk Signals и Behavioral Analysis.

Brute Force

Brute Force — массовый перебор Password одного Account.

Защита включает Rate Limiting, Lockout Policy, MFA и Detection.

Password Spraying

Password Spraying использует небольшой набор распространенных Password для большого числа Accounts.

Так атакующий пытается избежать блокировки одной учетной записи.

Credential Stuffing

Credential Stuffing использует пары Login и Password, ранее утекшие из других сервисов.

Уникальные Passwords и MFA значительно уменьшают риск.

MFA Fatigue

Атакующий может многократно отправлять MFA Requests, рассчитывая, что пользователь случайно подтвердит один из них.

Security Monitoring должен учитывать подобные аномалии.

Impossible Travel

Identity Platform может заметить два Login одного пользователя из географически несовместимых точек за короткий период.

Такой сигнал требует дополнительного контекста, поскольку VPN и Proxy способны влиять на Geolocation.

Risk-based Authentication

Система оценивает Risk Login.

При Low Risk пользователь входит обычным способом, а при High Risk требуется дополнительная MFA или доступ блокируется.

Account Lockout

После большого количества Failed Authentication Account может временно блокироваться.

Слишком жесткая Policy может использоваться злоумышленником для Denial of Service, поэтому настройки требуют баланса.

Password Policy

IAM может централизованно определять требования к Passwords.

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

Password Reset

Процесс восстановления Password является частью IAM Security.

Если злоумышленнику проще обойти Login через слабую процедуру Reset, сильный Password не помогает.

Self-Service Password Reset

SSPR позволяет пользователю самостоятельно восстановить доступ после дополнительной Identity Verification.

Это уменьшает нагрузку на Service Desk.

IAM и Help Desk

Service Desk часто работает с:

• Password Reset;
• Account Unlock;
• Access Requests;
• MFA Enrollment.

Интеграция с IAM помогает стандартизировать эти процессы.

IAM и HR-система

HR Platform может быть authoritative source информации о сотрудниках.

При создании или увольнении сотрудника событие автоматически передается в IAM.

HR System
↓
IAM
↓
Accounts / Roles / Access

Source of Truth

Для каждого Identity Attribute желательно определить авторитетный источник.

Например, Department приходит из HR, а Device Ownership — из MDM.

IAM и SaaS

Корпоративные SaaS Applications можно подключать к единому IdP.

Пользователь входит через SSO, а Provisioning Accounts выполняется автоматически.

Shadow IT

Если сотрудники самостоятельно регистрируются в SaaS с корпоративной почтой, IAM Team может не видеть эти Accounts.

Это создает проблемы Deprovisioning и Data Governance.

IAM в облаке

Cloud IAM управляет доступом к виртуальным машинам, Storage, Database, APIs и другим ресурсам.

В отличие от обычного Application Login, здесь Permissions могут напрямую влиять на инфраструктуру.

Cloud Role

Вместо постоянного Access Key пользователю или Workload можно назначать временную Role.

Это уменьшает необходимость хранить долгоживущие Credentials.

Cloud IAM и Least Privilege

Типичная ошибка — выдать разработчику полный Administrator Access, потому что так быстрее.

Безопаснее определить конкретные Actions и Resources, необходимые для работы.

IAM Policy в облаке

Policy может логически выглядеть так:

Principal: analytics-service
Action: read
Resource: reports-storage
Condition: production

Так Service получает только нужный доступ.

IAM и Infrastructure as Code

Roles и Policies можно описывать как Code и хранить в Version Control.

Это дает Review и Audit изменений.

Опасность неправильной IAM Policy

Слишком широкое правило вроде полного доступа ко всем Resources значительно увеличивает Blast Radius при компрометации.

IAM Misconfiguration является серьезным Cloud Security Risk.

IAM для Kubernetes

Kubernetes имеет собственную модель Authentication и Authorization, включая RBAC.

Корпоративную Identity можно интегрировать с Cluster Access, а Service Accounts использовать для Workloads.

Kubernetes Service Account

Pod может использовать Service Account для доступа к Kubernetes API или интегрированным системам.

Permissions следует ограничивать минимально необходимым набором.

IAM и Database

Database Access также требует Identity Management.

Лучше выдавать индивидуальные Accounts или централизованную Authentication, а не использовать общий Administrator Password для всей команды.

IAM и SSH

Административный SSH Access можно связывать с корпоративной Identity или централизованным управлением Keys и Certificates.

Это облегчает отзыв доступа после увольнения.

IAM и RDP

Windows Remote Access может использовать доменные Accounts, Groups, MFA и дополнительные Access Policies.

IAM помогает централизованно определить, кто имеет право подключаться к конкретным Servers.

IAM и VPN

VPN Authentication может быть интегрирована с корпоративным IdP.

Так MFA и Account Disable распространяются и на Remote Access.

IAM и Application Development

Разработчику не следует реализовывать собственную систему Password Authentication, если организация уже имеет надежный Identity Provider.

Использование стандартных протоколов уменьшает количество Security Logic внутри приложения.

Centralized Authentication

Приложение делегирует проверку Identity специализированному IdP, а само занимается бизнес-Authorization.

Это упрощает единое управление MFA и Sessions.

Broken Access Control

Даже правильная Authentication не защищает приложение, если Authorization реализована неверно.

Например, обычный пользователь изменяет URL и получает документ другого клиента.

IAM должен дополняться корректным Application-level Access Control.

IAM не заменяет безопасность приложения

IAM подтверждает Identity и может предоставить Roles, но приложение обязано проверять Permissions при каждой защищенной операции.

IAM и API Gateway

API Gateway может проверять Tokens до передачи Request Backend.

Это централизует часть Authentication и Authorization.

IAM и Microservices

В Microservices нужно управлять как User Identity, так и Service Identity.

Один Service не должен автоматически доверять другому только потому, что он находится во внутренней сети.

IAM и Service Mesh

Service Mesh может использовать Workload Identity и mTLS для Authentication сервисов.

Это дополняет классический IAM пользователей.

Identity Governance

IGA, или Identity Governance and Administration, расширяет IAM процессами Governance.

Она охватывает Access Requests, Reviews, Certification и Separation of Duties.

IAM и IGA

Access Recertification

Руководитель или владелец системы периодически проверяет, действительно ли сотрудникам нужны существующие Permissions.

Ненужные права удаляются.

Privilege Creep

Privilege Creep означает постепенное накопление прав.

Сотрудник несколько раз меняет должность, но старые Permissions не удаляются.

Через несколько лет его Account может иметь доступ к системам нескольких подразделений.

Как бороться с Privilege Creep

Нужны:

• автоматизированный Mover Process;
• Access Reviews;
• Role Design;
• отзыв неиспользуемых Permissions;
• контроль временного доступа.

IAM Logs

Критичные Identity Events должны централизованно логироваться.

Полезные события:

• Authentication;
• MFA Failure;
• Password Reset;
• Role Assignment;
• Token Creation;
• Account Disable;
• Policy Change.

Мониторинг IAM

Полезно отслеживать:

IAM как критичная инфраструктура

Центральный Identity Provider является одним из наиболее критичных компонентов компании.

Его компрометация может открыть доступ сразу к десяткам приложений.

High Availability IAM

Если IdP недоступен, сотрудники могут потерять возможность входить в корпоративные системы.

Поэтому Authentication Infrastructure должна учитывать отказоустойчивость и Disaster Recovery.

Break Glass Account

Для аварийных ситуаций иногда создают специальные Emergency Accounts, которые позволяют восстановить административный доступ при сбое основного Identity Provider.

Такие Accounts должны строго контролироваться и редко использоваться.

Защита IAM Administrator

Administrator IAM имеет особенно широкие возможности.

Для него необходимы:

• MFA;
• отдельный Admin Account;
• PAM;
• JIT Access;
• Audit;
• ограничение обычной повседневной работы.

Почему администратору нужны две учетные записи

Обычная Account используется для Email и Web, а административная — только для управления инфраструктурой.

Компрометация пользовательской Session тогда не дает автоматически Administrative Privileges.

Типичные ошибки IAM

1. Выдавать Administrator Access всем IT-сотрудникам.
2. Не удалять права после смены должности.
3. Оставлять Accounts уволенных сотрудников.
4. Использовать Shared Accounts.
5. Не включать MFA.
6. Хранить Service Account Password годами.
7. Не отзывать старые Tokens.
8. Создавать слишком широкие Cloud Policies.
9. Не проводить Access Reviews.
10. Не мониторить Identity Events.

Как внедрить IAM

Шаг 1. Провести инвентаризацию Identities

Нужно понять, какие Users, Service Accounts и Applications существуют.

Шаг 2. Определить Source of Truth

Для сотрудников им часто становится HR System или корпоративный Directory.

Шаг 3. Централизовать Authentication

Подключите основные приложения к Identity Provider.

Шаг 4. Включить MFA

Начните с Administrators и критичных приложений.

Шаг 5. Разработать Roles

Permissions должны соответствовать реальным Job Functions.

Шаг 6. Автоматизировать Joiner и Leaver

Создание и отзыв доступа не должны зависеть только от ручной заявки.

Шаг 7. Настроить Access Reviews

Регулярно проверяйте существующие Permissions.

Шаг 8. Отправлять события в SIEM

Identity Events должны участвовать в Security Monitoring.

Практический пример

Компания принимает нового бухгалтера.

HR создает сотрудника в кадровой системе и указывает Department Finance.

IAM получает событие и автоматически создает корпоративную Identity.

На основании Role пользователю выдаются:

Email
Corporate messenger
1C access
Document system
Finance shared folder

При первом Login сотрудник регистрирует MFA.

Через год его переводят в другой Department. IAM удаляет часть финансовых Roles и назначает новый набор доступа.

Еще через два года сотрудник увольняется. HR меняет его Status на terminated.

IAM автоматически блокирует корпоративную Account, отзывает Sessions, отключает VPN и удаляет доступ к SaaS Applications.

SIEM получает событие Deprovisioning и фиксирует завершение доступа.

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

IAM для бизнеса

Для бизнеса IAM решает не только Security, но и операционную задачу.

Новые сотрудники быстрее получают необходимые приложения, а IT Team меньше занимается ручным созданием Accounts.

При увольнении доступ закрывается централизованно, что уменьшает риск Orphan Accounts.

Также IAM дает Audit Trail: компания может определить, кто имел доступ к конкретной системе и на каком основании.

Преимущества IAM

• централизованная Authentication;
• SSO;
• MFA;
• автоматическое Provisioning;
• быстрое Deprovisioning;
• Least Privilege;
• Access Reviews;
• единый Audit;
• управление Cloud и SaaS Access.

Ограничения IAM

• сложность Role Design;
• зависимость от качества HR и Directory Data;
• критичность центрального IdP;
• необходимость интеграции приложений;
• риск ошибочных широких Policies;
• потребность в регулярных Access Reviews;
• IAM не заменяет Application Security.

Когда IAM особенно нужен

IAM особенно важен для компаний с большим количеством сотрудников, SaaS Applications, удаленной работой, Cloud Infrastructure и регулярными кадровыми изменениями.

Чем больше отдельных Accounts существует у одного сотрудника, тем выше ценность централизованного Identity Lifecycle.

Связанные термины

Краткий итог

IAM — Identity and Access Management, система управления цифровыми идентификаторами и доступом к корпоративным ресурсам. Она определяет, кто является пользователем или сервисом, как он проходит Authentication и какие действия ему разрешены.

IAM объединяет SSO, MFA, Roles, Policies, Provisioning, Deprovisioning и аудит. Одной из ключевых задач является управление полным жизненным циклом сотрудника: от автоматической выдачи доступа при приеме до быстрого отзыва всех Credentials и Sessions при увольнении.

Эффективная IAM-архитектура строится на принципах Least Privilege, индивидуальных Identities, регулярных Access Reviews и надежной Authentication. IAM при этом не заменяет безопасность приложений, EDR или SIEM, а становится фундаментом, на котором строится контролируемый доступ ко всей IT-инфраструктуре.