AuthN/AuthZギャップがもたらす影響

クラウドにおいては「アイデンティティが新たな境界である」という認識が一般的になりました。プレゼンテーションや記事に盛り込みやすい便利な表現ですが、これを実行可能な指針に落とし込むのは少々難しいものです。今回は、クラウドIAMのうち私が「AuthN/AuthZギャップ」と呼んでいる一点に絞って取り上げます。これはフェデレーションを利用する場合には常に生じる問題ですが、クラウド管理プレーンは常にインターネットに面しているため、クラウドではリスクがより高くなります。

まず、AuthNとAuthZの違いについて簡単に整理します。

• AuthNは認証です。自分がある主体であることを証明する行為を指します。私たち一般の人間にとっては、通常はユーザー名、パスワード、場合によってはMFAがこれに当たります。
• AuthZは認可です。ある操作が許可されているかどうかを確認する行為を指します。IaaSクラウドの場合、Webコンソールやポータルを使用しているときでも、これはほぼ常にAPI呼び出しに対応します。

認証と認可は異なるタスクであり、フローも異なります。Webサイトにログインする際には認証が行われ、通常はそれによってセッションが作成されます。何かをクリックするたびに認証情報を再入力する必要はなく、ブラウザが一定期間有効なトークンを送信するだけです。一方、認可は何らかの操作を行おうとするたびに、適切な権限があるかどうかが確認されるのが一般的です。

よく考えてみると、セッショントークンをいったん取得した後は、コード側で新たな検証を強制しない限り、再度チェックされることはありません。認証はそのセッションの間有効であり、したがって認可の範囲内であれば何でも実行できます。プラットフォームやシステムによっては、認証情報が失効させられていても、アカウントが完全に削除されていても、その一時的な認証情報が引き続き機能します。これがAuthN/AuthZギャップです。

私はクラウドインシデントレスポンスを教える際、このテーマに多くの時間を割いています。経験豊富なセキュリティ担当者であっても、その影響を必ずしも理解していないことがわかったからです。クラウドの認証情報が盗まれたケースを想像してみてください。認証情報を失効または削除しても、攻撃者がアクティブなセッションを開いたままであれば、許可された操作を引き続き実行できる可能性があります。これは…まずい状況です。

どう解決するか

その認証情報の使われ方にもよりますが、最も簡単な方法は通常、認可を変更することです。攻撃者が行うすべてのAPI呼び出しで評価されるため、当該エンティティに拒否ポリシーを適用する（または許可された操作を削除する）だけで済みます。これは最も単純な方法ですが、実行中のタスクを停止させてしまう恐れがあるため（盗まれた認証情報が必ずしもユーザーだけに紐づいているとは限りません）、常に最善とは限りません。クラウドプロバイダーのサポート状況によっては、次のような選択肢もあります。

• 条件を追加して、API呼び出しの送信元IPを制限する。
• 特定の日時より前に作成されたすべてのセッションを拒否する。

この問題は、クラウドプロバイダー内部よりも、クラウドプロバイダーへフェデレーションする場合に遭遇する可能性が高くなります。私がAWSで試したところ、IAMユーザーを削除した後、開いていたセッションのアクセス権はかなり速やかに失われました。しかし、外部のIDプロバイダーからフェデレーションする場合は必ずしもそうとは限らず、AWS内部でもアクティブセッション中に認証情報を再確認しないサービスがあります（例えば、アクセスを許可していたロールを削除した後も、Session Managerのセッションは15分以上生き続けました）。

これは知られていない重大な脆弱性というわけではなく、クラウドセキュリティ統制やインシデントレスポンスのプレイブックを策定する際に留意すべき事項です。認証情報の種類によって、またクラウドプロバイダー間でも同一プロバイダー内でも、有効期間は異なります。IDプロバイダーも要因となり、さらにどこで認証情報を失効させようとするかも影響します。例えば、Active DirectoryのユーザーをAWSにフェデレーションし、そのユーザーがAWSでロールを引き受けてそのロールのセッション認証情報を取得している場合、ADでそのユーザーを制限したとしても、引き受けたロールの認証情報を失効または制限する必要があります。AWSは、セッション終了時に認証を再検証するまで、ADから得たそのユーザーのセッションが無効になっていることをまったく認識しません。

社内では、当社のAuthorization Controlツールの利用に切り替えました。このツールはChatOps経由で制限付きのセッション作成をサポートし、開発者の作業を妨げるような摩擦を一切生じさせません。まだ一般提供はしていませんが、早期アクセス期間中に試用をご希望の場合は、rich.mogull@firemon.com まで直接メールでご連絡ください。