Операции, требующие root-логина. #root

Если у вас активно используется #AWS_Organizations, то стоит задуматься над тем, чтобы прописать пароли у root-юзеров в созданных суб-аккаунтах (что не часто делается, особенно если они создаются автоматически).

Указание фейковой почты для #root_user уязвимо с точки зрения безопасности. Лучшей практикой является установка пароля для рута и включение #MFA на какое-то условно защищённое устройство (и, к примеру, помещённое в сейф).

Кроме того не стоит забывать, что Амазон шлёт некоторые важные (в т.ч. критические - взлом и т.п.) #notifications на почту root-юзера. Это можно в некоторой мере решить, указав Alternate Contacts в настройках аккаунта, однако некоторые сервисы (если не ошибаюсь, #SES), могут слать notifications лишь на рут-почту.

#security #best_practices

В продолжение темы защиты #root_user — для особо опасливых можно посоветовать накрыть всё это дело сверху #SCP политикой для #AWS_Organizations, запрещающей работу из-под рута.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:root"
    }
  }
}

Правда некоторые сервисы под капотом используют (требуют) рута, потому стоит протестировать на чём-то неважном (возможно разбанить нужные сервисы, требующие root).

#paranoid #security

Некоторые операции в AWS консоли требуют именно рута (т.е. нужно логиниться как #root_user). Чтобы не гуглить в поисках объяснения, почему у вас в консоли нет какой-то вещи, в то время, как в документации или какой-то статье она есть, то стоит периодически заходить сюда:

https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html

Например, это будет полезно, если вы вдруг захотите включить мегазащиту MFA Delete на свой бакет с нажитыми за долгие годы бесценными логами или срочно потребуется посмотреть в консоли Account Canonical User ID (он же #s3_canonical) — всё это также должно делаться из-под рута.

⁠Сообщения Амазона на дополнительный ящик

Когда возникает требование дублировать сообщения, которые Амазон шлёт на почту #root-юзера (например, вы передаёте аккаунт заказчику, а его нужно дальше сопровождать и, значит, продолжать получать сообщения), то для этого есть возможность добавить Alternate contacts в менюшке My Account:

https://aws.amazon.com/premiumsupport/knowledge-center/account-email-cc/

Защита root-аккаунта или тысяча первое китайское предупреждение

Спички детям не игрушка, мойте руки перед едой, используйте двухфакторную авторизацию и не давайте #root-доступ в #root-аккаунт:

https://medium.com/@victoryteam/nightmare-scenario-employee-deletes-aws-root-account-29e28af15436

p.s. Обсуждение на реддите:

https://www.reddit.com/r/aws/comments/cgty96/nightmare_scenario_employee_deletes_aws_root/

#плач_Ярославны

Root access management

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html

С помощью Root access management можно централизованно на уровне всей организации выключить root-пользователей оптом сразу во всех под-аккаунтах.

Чтобы выполнить действия, требующие именно root-юзера, например, снятие неудачно применённой S3 bucket policy, то используем perform a privileged task. Когда можно переключиться из главного аккаунта в под-аккаунт в специальную "short-term" root-сессию.

Таким образом у вас (у нас) появляется официальная возможность послать всех безопасников с их проверками на root-пользователей нафиг упростить механизмы соответствия compliance требованиям.

P.S. Кто не может найти у себя такую картинку — это доступно только в главном (management) аккаунте или аккаунте delegated administrator for IAM.

#IAM #Organizations #root