MFAだけでは不十分なとき

クラウドセキュリティの第一のルールは「常にMFAを使用すべし」です。なぜでしょうか。パブリッククラウドコンピューティングに移行すると、実質的にすべての管理インターフェイスを単一のポータルまたはAPIに集約し、それをユーザー名、パスワード、そして（場合によっては）MFAで保護した状態でインターネット上に置くことになるからです。フェデレーションを利用している場合でも同様です。

しかし実際には、MFAでさえ常に十分とは限らないことが、複数の大規模な侵害事例、たとえばUberでの事例から明らかになっています。

これはクラウドと従来型インフラストラクチャの違いの中でも、最も重要な理解すべき点の一つであり、「アイデンティティが新たな境界である」という言葉が繰り返し聞かれる理由でもあります。クラウド以前は、プライベートネットワークの内側から（あるいはVPNや踏み台サーバーのような管理されたアクセスポイントを通じて）データセンターを管理していました。クラウドではそれらがすべてデフォルトでインターネット上にあり、securely に閉じることは困難です。特に、リモートの従業員や管理者をサポートする機会が増えている現在では、なおさらです。

MFAは、ユーザーおよび管理者の認証を保護する有効な手段です。選択肢は数多くあり、ある程度安全なもの（メッセージベースのMFA）から、非常に安全なもの（ハードウェアキー）まで存在します。しかしMFAを使っていても問題となるのは、ユーザーが永続的な権限を伴う永続的なアクセスを持っている点です。ユーザーにロールを付与すると、認証後はいつでもその権限を使用できてしまいます。攻撃者はこれを承知しており、認証済みアクセスを獲得するためのさまざまな手法を編み出しています。攻撃者は次のようなことを行います。

• 静的な認証情報を悪用する。特にMFAが使われていない場合に顕著です。
• 一部のMFAを突破する。たとえば、SIMスワップによって携帯電話宛てのテキストメッセージを傍受します。
• ソーシャルエンジニアリングによって管理者にMFAを無効化させる、または攻撃者の管理下にあるデバイスへリセットさせる。
• ソーシャルエンジニアリングによってユーザーからMFAコードを詐取する。
• 認証済みのユーザーのシステムからセッション認証情報を窃取し、攻撃者の管理下にあるシステムから使用する。

攻撃者はアクセスを獲得すると、権限の調査を開始し、最終的にはそれを悪意ある活動に利用します。

最小権限という嘘

根本的な問題は、ある時点で必要とされる作業に基づいてではなく、将来必要になるかもしれない作業に基づいて権限を付与していることです。から明らかになっています。 ユーザー、特に管理者は、あらゆる操作に対応できる最大限の権限セットを保持しています。 世界中のあらゆるセキュリティ標準がIAMはデフォルト拒否かつ最小権限であるべきだと述べていますが、それはある種の嘘です。なぜなら、「最小権限」のセットは、いずれかの時点で必要となる最大限の権限セットによって定義されているのであって、常時必要なものから明らかになっています。

によって定義されているわけではないからです。ユーザーがロールを切り替え、セッションごとに異なる権限を使用できるようにしている場合でも、ほぼ常に、ユーザーは望むときにそれらのロールを利用できる状態にあります。実際には、最小権限はユーザー単位だけでなく、時間的にも制限されるべきです。従来、私たちはロールを割り当てることで権限を管理し、ロールはあるスコープにおける権限を持ちます。「あなたはこの5つのアカウントでは管理者で、残りの98アカウントでは一般ユーザーです」といった具合です。多くの場合、ユーザーに複数のロールを割り当てることさえあります。それらは権限が統合されるか、作業内容に応じてロールを切り替えられるようになっています。

もし永続的な権限を排除したとしたら、攻撃者にとってどれほど困難になるか想像してみてください。ユーザーは認証すればすべての権限を利用できるのではなく、ごく限られた権限のみでアクセスし、害を及ぼしうる操作については権限昇格を要求しなければならなくなります。

動的な認可によるセキュリティの強化

MFAやその他の認証レベルのセキュリティを廃止しようと提案しているわけではありません。それらは依然としてきわめて重要ですが、十分でない場合があります。これは、本質的にインターネットへの露出度が高いクラウドセキュリティにおいて特に当てはまります。しかしクラウドには利点もあり、その中にはセッションベースのフェデレーションや、（個々のAPIコールにまで及ぶ）きめ細かな認可が含まれます。

将来必要になりうるすべての権限への永続的なアクセスをユーザーに与えるのではなく、より限定されたアクセスを与え、ユーザーは必要に応じて昇格された権限へのアクセスを要求します。これは新しい概念ではなく、特権ユーザー管理製品が長年利用してきた方式です。しかしそうした製品は、プロキシ経由のセッションや一時パスワードのローテーションといった扱いにくい手法に依存していることが少なくありませんでした。クラウドは本質的により柔軟です。ネイティブのIAMモデルはその性質上セッションベースであり、権限はポリシードキュメント（通常はJSONで記述）で定義されるためです。

当社のFireMon Authorization Controlのようなツールは、このように機能します。オープンソースの例としては、Netflix ConsoleMeをご覧ください。ユーザーは必要なときにアクセスを要求し、プラットフォームはポリシーに基づいて承認に必要な条件を判断します。マネージャーや同僚の承認といった条件が満たされると、ユーザーはそのセッションの間そのロールを使用する認可を得ます。プラットフォームは「要求元のIPアドレスからのセッションのみを許可する」といった条件を挿入することもできます。こうした要求は通常アウトオブバンドで行われ、承認にはChatOpsのようなサイドチャネルを用いるため、特に機密性の高い本番環境へのアクセスについては、意図的に目立つプロセスになります。

認可レベルのセキュリティは、開発者やユーザーからセキュリティ管理者まで、実際にすべての人の負担を軽減します。潜在的に必要となる権限の全体像を事前に把握しておく必要はありません。その代わりに、ユーザーは必要なときに必要なものを要求します。ポリシーが、セキュリティを損なうことなくそのアクセスを提供するための最も摩擦の少ない経路を判断します。ChatOpsのようなツールを使えば、開発者は新しいアカウントへのアクセスを要求し、数秒以内に回答を得られます。チケットシステムに申請して数日から数週間かかるのとは対照的です。

認可にセキュリティを組み込むことで、摩擦とオーバーヘッドを削減しながら、認証情報の窃取や認証の侵害による影響を低減できます。