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

Можно поставить WAF поверх приложения. Но он не исправит модель полномочий. Можно включить MFA. Но он не исправит сервис, который имеет доступ ко всей базе без необходимости. AMPE использует Security Architecture & IAM, чтобы trust boundaries, identity, access, encryption, secrets и auditability были частью базовой конструкции системы.

Начать диагностику

IAM начинается не с логина

Identity отвечает на вопрос: кто или что выполняет действие.

Это может быть: сотрудник; клиент; подрядчик; service account; machine identity.

Authentication подтверждает identity.

Authorization определяет, что ей разрешено.

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

Rbac хорошо работает, пока роль действительно описывает права

«Менеджер». «Администратор». «Оператор».

По мере роста системы роль может стать слишком широкой.

Тогда появляются attribute-based условия: подразделение; регион; владелец объекта; сумма; риск; время.

AMPE использует RBAC, ABAC или комбинацию по реальной модели полномочий.

Когда мы используем этот подход

При проектировании новой платформы.

Когда права пользователей накопились исторически.

Когда несколько приложений используют разные модели identity.

Когда нужен SSO или federation.

Когда сервисы взаимодействуют от имени машин.

Когда критические операции требуют segregation of duties.

Когда секреты и ключи хранятся неуправляемо.

Least privilege — это постоянное состояние, а не разовая настройка

Сотрудник сменил роль. Проект закончился. Временный доступ остался. Service account получил новые права.

Без lifecycle access только растёт.

AMPE связывает provisioning и deprovisioning с событиями жизненного цикла identity.

Secret не должен становиться конфигом, который «просто не коммитят в git»

Пароли, API keys, certificates и encryption keys требуют: централизованного хранения; rotation; access control; audit; revocation.

Secrets management — отдельный контур, а не дисциплина разработчика.

Encryption at rest и in transit не решает вопрос, кто имеет доступ к расшифрованным данным

Шифрование важно.

Но приложение всё равно должно прочитать данные в открытом виде, чтобы их обработать.

Поэтому ключи, runtime permissions и boundaries критичны не меньше самого алгоритма.

Audit trail должен быть достаточно надёжным, чтобы ему можно было доверять при разборе

Если пользователь с административными правами может изменить и данные, и журнал этого изменения, auditability слабая.

Для критических контуров AMPE рассматривает append-only или immutable механизмы, отдельные права и защищённое хранение событий.

В контуре AMPE

Identity подтверждается.

Policy определяет права. Application применяет authorization. Secret management защищает credentials. Encryption защищает данные. Audit trail фиксирует критические действия. Monitoring ищет отклонения. Lifecycle своевременно меняет доступ.

Так безопасность остаётся связанной с архитектурой работы, а не живёт отдельным perimeter-слоем.

Что меняется в результате

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

Временный доступ не превращается в постоянный.

Machine identities управляются так же осознанно, как пользователи.

Секреты получают жизненный цикл.

Критические действия становятся трассируемыми.

И главное — trust model системы становится явной и проверяемой.

Первый шаг

С чего начать

Для начала достаточно описать, где сегодня сложнее всего ответить на вопрос «кто, к чему и почему имеет доступ». Диагностика покажет, где проблема находится в identity, policy, lifecycle, secrets или архитектурной границе доверия.

Начать диагностику