Multi-party approval は AWS Organizations の機能で、あらかじめ定義した高リスク操作の集合を、指名された複数の人間による定足数が帯域外で承認するまでブロックする。たとえ有効なものであっても、単一の認証情報セットだけでは引き金を引けなくなる。リクエスト元が操作を開始し、別の approval team が専用ポータルでそれをレビューし、チームの approval threshold が満たされて初めて操作が実行される。

これは「四つの目」の原則を、Runbook や Slack メッセージではなく API レイヤーで強制するものだ。「2 人が承認しなければならないというポリシーがある」という状態と、「プラットフォームが 2 人の承認なしには物理的に処理を拒否する」という状態の間にある隙間を埋める。

実体は何か

Multi-party approval (MPA) は AWS Organizations の内側に位置し、人間の ID については IAM Identity Center に依存する。あなたは approval team、つまり ID ソースから引き出した承認者の集合を定義し、そこに approval threshold、すなわち protected operation を実行できるようになる前に「はい」と言わなければならない最小人数を割り当てる。

次に、特定の操作を protected としてマークする。その時点以降、protected operation を呼び出した者は即座に結果を得られない。得られるのは保留中のリクエストだ。MPA はチームの全承認者にメールを送り、各承認者が approval portal を開いてリクエストをレビューし、承認または拒否する。threshold に達すると、元の呼び出し元の操作が実行を許可される。承認は事後通知ではなく、ゲートそのものだ。

用語

  • Approval team: IAM Identity Center ユーザーに裏打ちされた、名前付きの承認者グループ。
  • Approval threshold: 何人の承認者が承認しなければならないか。threshold が 2 の 3 人チームなら、そのうち任意の 2 人が操作のブロックを解除する。
  • Protected operation: ゲートの背後に置いた具体的なアクション。
  • Approval portal: 承認者がレビューし応答する帯域外のサーフェス。リクエストを行ったコンソールセッションとは意図的に分離されている。

フローの動作

プロセスは 3 ステップで、その間の分離こそが本質だ。

  1. リクエスト。 ユーザー (または自動の呼び出し元) が protected operation を呼び出す。実行する代わりに、AWS は承認セッションを作成しチームに通知する。
  2. 承認セッション。 承認者はリンク付きのメールを受け取り、ポータルを開き、何が、誰によって、どのリソースに対してリクエストされているかを正確に確認する。各自が独立して承認または拒否する。
  3. 実行。 承認が threshold に達すると操作が実行される。セッションがタイムアウトしたり threshold が満たされなかった場合、操作は決して行われない。

リクエスト元は自分のセッション内から自分のリクエストを承認することはできない。承認は別のサーフェスで、別の ID に紐づいて行われる。盗まれたセッショントークンや侵害された CI ロールだけでは不十分になるのは、これが理由だ。

セキュリティ上の意義

価値はメールやポータルそのものにあるのではない。単一の侵害されたプリンシパルが迂回できない場所、すなわちアプリケーションの下層、プラットフォームに制御が存在することにある。

単一の侵害点を取り除く

壊滅的なクラウドインシデントの大半は、過大なリーチを持つ単一の ID に帰着する。漏洩した長期キー、フィッシングされた管理者、過剰なスコープを持つ自動化ロールなどだ。あなたの一週間を台無しにしうる一握りの操作について、MPA は「侵害された認証情報 1 つ」を「同時に N 人の独立した人間も破る必要がある」に変える。これは別次元の攻撃難度だ。

職務分掌を API で強制する

職務分掌は通常コンプライアンス文書の中に存在し、実務では死んでいる。急いでいるエンジニアが機微な変更の両方の半分を実行することを、何も止めないからだ。MPA はそのルールをコントロールプレーンへ移す。2 つ目の署名を強制するのは善意ではなくプラットフォームになる。

ランサムウェアと破壊的なインサイダーへのブレーキ

古典的な破壊の手口は、まずバックアップを削除し、次にデータを削除することだ。保護対象の復旧ポイントを削除または変更する操作が定足数の背後にあれば、1 つの ID を掌握した攻撃者でも、最後の復旧手段を静かに破壊することはできない。同じブレーキは、正規のアクセス権を持つ不満を抱えたインサイダーにも適用される。

防御できる監査証跡を生成する

すべての protected operation には、誰がリクエストし、誰が承認し、いつ行われたかの記録が残るようになる。SOC 2、ISO 27001、PCI DSS、あるいは社内のインシデント後レビューにおいて、「このアクションの承認を見せてほしい」は発掘作業ではなくクエリになる。

適する場所、適さない場所

Multi-party approval を使うべき場面見送るべき場面
操作がまれで、影響範囲が大きく、不可逆である操作が頻繁で、即時実行が必要である
AWS Organizations を IAM Identity Center とともに運用しているOrganizations も Identity Center もないスタンドアロンアカウントを運用している
コンプライアンスや Zero Trust のために分散した承認が必要であるチームやワークフローの管理オーバーヘッドを正当化するほどのリスクがない
最後の砦であるバックアップの削除や変更を保護したい人間を介さず無人で動く自動化が必要である

MPA は毛布ではなくメスだ。誤操作が回復不能になる操作にこそ適用する。論理的にエアギャップされたバックアップボールトの破壊、組織レベルのガードレールの解体、復旧ポイントの削除などだ。チームが 1 日に 40 回実行するような操作には適用してはいけない。さもないと全員が承認を機械的に押すよう訓練されてしまい、それは制御がまったくない状態より悪い。

計画すべき失敗モード

  • 承認者の在席。 threshold が 2 でチームにも 2 人しかいなければ、1 人の休暇で正当な緊急対応が止まりうる。チームは threshold より大きく構成し、名簿を最新に保つこと。
  • break-glass の緊張。 本物のインシデントでは protected operation が すぐに 必要になることがある。時間外にどう承認者へ到達するかを事前に決め、それが重要になる夜の前にリハーサルしておくこと。
  • 承認疲れ。 保護しすぎると承認者は読まなくなる。制御は反射的なクリックへと劣化する。保護リストは短く、真に重大なものに保つこと。
  • ID ソースへの依存。 MPA は IAM Identity Center に寄りかかる。それが誤設定されていたり利用不能であれば、承認経路も同様だ。これはレジリエンス計画の外ではなく内側に属する。

まとめ

Multi-party approval は、単にフラグを立てるのではなく攻撃者にとっての計算を変える、数少ない AWS の制御の 1 つだ。単一のミスや単一の盗まれた認証情報が壊滅的になる小さな操作の集合について、定足数ゲートはインシデントと災害を分ける違いになる。狭く適用し、approval team を適切に配置し、break-glass 経路をリハーサルすること。

次に読む

AWS の認証情報を保持するエージェント型システムを構築している? 同じ定足数の考え方は自律的なアクションにも当てはまる。フィールドノートは ercan.ai を参照。AWS、クラウドセキュリティ、プラットフォームガバナンスのコンサルティングについては ercanermis.com から。