はじめに

制約をつけたSCPを観察用のOUにアタッチし、そのOUに実験対象のアカウントぶちこんで、挙動を観察する！ということをしてみました。

AWS Organizationsとは？

複数のAWSアカウントを「組織(Organization)」という単位でまとめ一元管理できるサービス 1つの「管理アカウント」の下に、複数の「メンバーアカウント」を紐づけます。これによりマルチアカウント管理が非常にやりやすくなります。

主な機能

今回やったこと

AWSの特定のサービス障害など発生したときの挙動を確認するため
SCP(サービスコントロールポリシー)でガチガチに権限を絞ったOU配下に、実験対象のアカウントを移動させ、ワークロードの処理がどうなるか確認します。

対象ワークロード

「受信メールをフィルタリングして必要な場所に通知を出す社内サービス」の開発環境用アカウントを対象にしました。

アーキテクチャからメインの流れだけ抜き出してみます。

  • ①②受信したメールを
  • ③④処理しやすい形に変換し保存
  • ⑤フィルタ条件に沿って適切な「通知待ちキュー」にメッセージを送り
  • ⑥⑦各種外部サービスに通知を行う

という流れです。

かけた制限

「権限を奪うSCP」には以下を設定しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Deny",
      "Action": [
        "SNS:*",
        "SES:*",
        "S3:*",
        "Lambda:*",
        "Dynamodb:*",
        "SQS:*"
      ],
      "Resource": "*"
    }
  ]
}

どうなるか？予想

前述のSCPをつけたOU配下に開発用アカウントを移動すると、ワークロードはどこで失敗するでしょうか？最後まで成功するでしょうか？
(本記事にはワークロードの詳細は記載していないので、想像で考えないといけないですがmm)

ヒントは「 SCPの影響範囲は IAM ユーザーとロールのみ」という仕様です。

結果

このワークロードがSlackへ通知すべきメールを送ってみました
しかしメールはSlackに通知されません。

みてみると「③変換処理のLambda」でメール生データをreadしにいくところでコケています。

[ERROR] ClientError: An error occurred (AccessDenied) when calling the GetObject operation: Access Denied Traceback (most recent call last):

①SES -> ②SNS -> ③Lambda の呼び出しまではイベントによって繋いでいるのでIAM権限は利用しないのでSCPによって制限をかけていても正常に動きます。

そのあと③のLambdaは実行ロール(IAMロール)から引き継いだ認証情報を使ってS3から生データをreadするので、ここで失敗しました。(「S3:*」をDenyしているのでそこでひっかかった)

ちなみに何処でコケたか確認するついでにマネジメントコンソールからLambda関数を確認しにいったら、「Lambda:*」もDenyしているので見れませんでした。(〜with an explicit deny in a service control policy)。
障害発生時はそのサービスリソースの状況も確認できないことがあるので、そういったことを思いださせてくれます。

考察

失敗を検知できる状態か？失敗対処を特定したりリカバリーに流すことはできるか？オブザーバビリティ系サービスにはどう記録されるか？
など考えるきっかけの１つとしてはありかなと思いました。

  • この方法のいいところ
    • 実施が簡単、後片付けも簡単
    • IAMロールを介している部分であれば、特定サービスにアクセスできない障害をあるていどシミュレートできる
  • この方法のイマイチなところ
    • 強力な制限をかけるSCPを作って検証用OUとはいえアタッチし、アカウント移動するのでミスがあると事故になる。
      • 対策:実験を行うユーザーのOrganizations:MoveAccount権限で許可するアカウントIDを限定すればリスク低減はできそう(未検証)
    • SCPで縛れるのはIAMユーザー、IAMロールのみなのでシミュレートできる状況は限定的

終わりに

今回は「SCPでガチガチに絞ったOUにアカウント突っ込めば、障害のシミュレートができるんじゃないか？」をやってみました。対象アカウントそのものは触らずに上位の概念で制限を注入できるのがおもしろいと感じました。

アイレットでは関連するサービスとして「AWS利用料割引」「cloudpackサポート」といった特典を受けながらAWS Organizationsも利用いただける「AWS 請求代行サービス + Organizations」を提供しています。
また、「AWS Organizationsの活用事例紹介イベントのページ」では、AWS Organizationsの基礎から活用事例まで紹介した動画アーカイブが視聴可能です。
複数AWSアカウントを利用・管理されいてる方は、ご覧いただけると！

では、また。