💥

[やらかし][AWS]Service Control Policy でロールの予期せぬ削除を防ごうとしたら権限がなくなった話

3 min read

こんにちは、@hirosys です。
こちらは Zenn での1つ目の記事です。
今回は、やらかし先生ということで失敗談からの学びをお伝えします。

なにをやらかしたのか

タイトルで出落ち感満載ですが。。。
AWS Organizations の Service Control Policy(SCP) で IAM Role の予期せぬ削除を防ごうとしたら権限がなくなってしまいました。

背景

AWS Organizations を利用して社内のエンジニア向け学習用として、メンバーアカウントを多数開設し運用しています。それらのメンバーアカウントは、アカウント作成時にマネージメントアカウントからのアクセスを受け入れるための IAM Role を作成しています。

この IAM Role を利用者から削除させないようにするため、 SCP を使って設定したのがことの発端でした。

やったこと

IAM Role の削除を防ぐことを目的としていたので、 IAM の DeleteRole アクションを拒否(Deny)すればよいと判断し、以下のような SCP のポリシー(一部抜粋)を作成し適用していました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteRole",
      "Effect": "Deny",
      "Action": [
	      "iam:DeleteRole"
	],
      "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  ]
}

このポリシーをテスト用のメンバーアカウントに適用し、動作確認を行いました。
確認内容は以下の通り。

  1. テスト用メンバーアカウントへブラウザからアクセス
  2. 削除を防ぎたい IAM Role を削除する操作を実施する(マネージメントコンソールから対象の IAM Role を削除する操作を行う)
  3. 権限不足といったエラーにより削除できないことがわかる
  4. その操作後も その IAM Role を使ってメンバーアカウントへアクセスし操作が行える

上記の確認を行ったところ、期待した通りに「権限不足」を示すエラーが表示され、削除されませんでした。

うんうんよかったよかった。

・・・とは、なりませんでした。

何が起きたのか

「確認内容4:その操作後も その IAM Role を使ってメンバーアカウントへアクセスし操作が行える」をマネージメントコンソールで実施したところ、違和感を覚えました。

上図は、親の顔よりもよく見ている Amazon EC2 のダッシュボードです。
まず第一声は「どういうこと!?」でした。

削除は拒否された。IAM Role を使ってメンバーアカウントへのアクセスはできている。
なのに、ダッシュボード上に列挙される「API エラー」の山々。

ここで、気づいたあなたはさすがです。

IAM Role は削除されていません。
動作として正しいです。ポリシーの Deny が想定通り効いています。

そうです。対象の IAM Role から IAM ポリシーがデタッチされていたのです。

ΩΩ Ω<ナ、ナンダッテー

おそらく、マネージメントコンソールでの IAM Role の削除は IAM ポリシーのデタッチが同時に行われるようです。
流れをまとめたのが以下の図です。

みんな大好き AWS CLI で IAM ポリシーがアタッチされている IAM Role を削除しようとするとどうなるかを確認しました。

[cloudshell-user@ip-10-0-102-222 ~]$ aws iam delete-role --role-name test

An error occurred (DeleteConflict) when calling the DeleteRole operation: Cannot delete entity, must detach all policies first.

AWS CLI では、「まずは、全てのポリシーをデタッチせよ。話はそれからだ」とエラー終了します。

つまり、ユーザビリティを考慮したマネージメントコンソールの動作(IAM Role の削除時にポリシーもデタッチする)によって引き起こされた事象と言えます。

どう対処したのか

もう答えは出ていますね。IAM Role からポリシーのデタッチができないようにします。つまり、DetacheRolePolicyアクションも Deny の対象にしました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteRole",
      "Effect": "Deny",
      "Action": [
	      "iam:DeleteRole",
	      "iam:DetachRolePolicy"
	],
      "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  ]
}

改めて動作検証し、マネージメントコンソールからの IAM Role 削除でもポリシーのデタッチは起きませんでした。安心して寝られますね。

教訓、まとめ

マネージメントコンソールでは、1操作1APIになっていないことがあります。そのこと自体は、利便性の向上や直感的な操作感のために重要なことではあります。

しかし、SCP や IAM ポリシーで制限をかける際には、この1操作1APIではないために意図しない処理が見えないところで動き出し、結果的に環境破壊につながるということがありえます。

STS 用の IAM Role のみしかない環境の場合、復旧には(おそらく)Rootユーザーでないとならないことが往々に生じます。そのため、Rootユーザーの利用申請などをしないとならないケースがでてきたり、本番環境ではインシデント扱いになりかねません。本やらかしを参考にお気をつけて、よいポリシーライフを謳歌ください。