re:Invent 2024: AWSがRoot userセキュリティ強化 - MFA必須化とPasskeys導入
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Secure by design: Enhancing the posture of root with central control (SEC232)
この動画では、AWSのRoot userアカウントのセキュリティに関する新機能と方針の変更について詳しく解説しています。AWS OrganizationsとControl Towerで利用できる新機能「Central Management for Root User Access」により、メンバーアカウントのRoot user認証情報を一元管理できるようになりました。また、2024年5月からRoot userに対するMFAの強制適用を段階的に開始し、FIDO2 Passkeysのサポートも導入されました。MFAの強制適用により、4月から10月の間に75万人以上のユーザーが新たにMFAを有効化し、2025年春からはMember AccountsでもMFAが必須となることが発表されています。Secure by designの原則に基づき、セキュリティをデフォルトで組み込む方針を強化していく姿勢が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのセキュリティエキスパートによる講演の開始
みなさん、こんにちは。ようこそ。Rootアカウントのセキュリティについて興味をお持ちの方は、まさに適切な場所にいらっしゃいます。私はArynn Crowと申します。AWSのPrincipal Product Managerとして、アカウント保護に注力しており、Amazonで合計12年間勤務してきました。そして本日は素晴らしい共同発表者がおります。私はJason Garmanです。AWSのPrincipal Security Solutions Architectとして2年半勤務しており、新機能について皆様と共有できることを大変楽しみにしています。
本日は盛りだくさんのアジェンダをご用意しています。まず、Secure by designについて、そしてAWSアカウントアクセスの歴史、AWSのRootアクセスの将来、AWSにおけるMFA、そして今後変更されるMFA要件についてお話しします。
Secure by designとAWSアカウントアクセスの進化
Secure by designについて話す際、私たちが意味しているのは、セキュアなソフトウェアとインフラストラクチャを開発するための一連の原則と実践、そして運用とメンタルモデルのことです。これは、セキュリティを単なる機能の集合としてではなく、設計から開始し、リリース、そしてその先まで組み込むことで、お客様に適切なデフォルト設定を提供し、適切なセキュリティの判断を容易にし、不適切な判断を困難にすることを意味します。
AWSでは、初日からSecure by designを実践してきました。この考え方は組織のあらゆるレベルに浸透しています。今週のre:inventの他のセッションに参加された方は、「セキュリティは私たちの最優先事項です」といった言葉を耳にされたかもしれませんが、これは私たちにとって単なるスローガンではありません。これは、組織のあらゆるレベルで、管理するすべてのライフサイクルの段階において、互いに責任を持って実践している取り組みなのです。これらの原則を実践に移してきた例をいくつかご紹介します。例えば、私たちのサービスではデフォルトパスワードを使用せず、代わりにユーザーごとに一意のパスワードを提供しています。また、オープンソースの認可ポリシー言語と認可エンジンであるCedarで使用されているRustのようなメモリセーフな言語への投資を増やしています。さらに、MFAや最近リリースされたResource Control Policiesなど、セキュリティの基本となる機能を追加料金なしで提供しています。
リリース時点でセキュアだったからといって、単に機能をリリースしてそれで良しとするのは十分ではありません。デジタルトランスフォーメーションによる世界の変化に伴い、悪意のある攻撃者が使用する手法も変化し進化していきます。そのため、適切なセキュリティ態勢とは何かを常に再評価する必要があります。私たちは、お客様に適切なセキュリティ態勢を提供するために、必要に応じてポリシーの変更を行うことができますし、実際に行っています。
例えば、 2022年には、S3のデフォルトバケットポリシーを変更し、デフォルトでパブリックアクセスをブロックするようにしました。また、Amazon DynamoDBのリソースベースポリシーをリリースした際も同様の対応を行い、デフォルトでパブリックアクセスをブロックする設定としました。
進化について語る際、私たちはもう少し広い視点で見る必要があると思います。なぜなら、この変化はAWSだけにとどまらない大きなものだからです。この変化が最も顕著に表れているのが、セキュリティ境界の進化についてです。これまで、優れたエンタープライズセキュリティの特徴は、主にファイアウォールやアクセスコントロールリストなどのネットワーク層で定義されていました。しかし、私たちの働き方が変化するにつれて、この考え方も変化してきています。現在では、BYOD、IoT、地理的に分散したチームなど、新しい要素が加わっています。ネットワークコントロールは依然として重要ですが、それだけでは十分ではありません。これは二者択一の問題ではなく、両方が必要なのです。多層防御戦略やゼロトラスト戦略において、アイデンティティ層でのコントロールがますます重要視されています。なぜなら、アイデンティティが、環境内でユーザーがどのようなリソースにアクセスし、どのようなアクションを実行できるかを決定する重要な要素となっているからです。例えば、所属グループ、職務、場所、特定のサービスにアクセスすべき時間帯などが考慮されます。これは、今後、強力な認証と詳細な認可コントロールの重要性が高まることを意味しています。
このセキュリティ境界の変化に伴い、新たな警戒すべきリスクも出現しています。COVID-19パンデミック以降、複数の業界ソースが報告している現象を私たちも確認しています。サイバーインシデントの試みは増加の一途をたどっており、その攻撃の多くはアイデンティティ境界の中核要素であるユーザーの認証情報に焦点を当てています。例えば、2024年のVerizon Data Breach Reportによると、調査対象となった全体の大部分を占めるWebアプリケーション攻撃のうち、77%が盗まれた認証情報を使用し、さらに21%が総当たり攻撃を試みていたことが分かりました。これらの事実は、私たちにパスワードに関する問題があることを示しています。
パスワードには様々な問題があります。ここに表示されているような弱いパスワードがよく使用されています。私も愛犬が大好きですが、それを自分のパスワードにはしていないことを約束します。試さないでくださいね。また、パスワードはウェブサイト間で再利用されることがあり、これは特に問題です。なぜなら、そのウェブサイトの1つが侵害された場合、盗まれた認証情報が他のオンラインサービスで使用される可能性があるからです。さらに、フィッシング攻撃の対象にもなりやすいのです。
パスワードの弱点を補うために、私たちは多くの対策を講じています。これらの中には、これまで公に話してこなかったものもあり、あまり馴染みがないかもしれません。その一つは、弱いパスワードや第三者のデータ侵害で露出したパスワードのリストを特定するために、様々なオンラインソースを監視していることです。そして、影響を受けた認証情報を使用してRootパスワードを作成または更新することを防いでいます。オンライン上で新たなデータ侵害が発生し、お客様が影響を受けたパスワードを使用していることが判明した場合、次回のログイン時にパスワードのリセットを要求し、本人確認のための追加チャレンジを実施します。さらに、アカウントで異常なアクティビティが検出された場合、RootユーザーのメールアドレスにワンタイムPINチャレンジを発行することもあります。
このような追加のステップを講じてパスワードベースの認証を強化しようとしても、パスワード単体では本質的に脆弱性が残ります。しかし幸いなことに、パスワードベースの認証に対してシンプルでエレガントな解決策があります。それが Multi-Factor Authentication（MFA）です。皆さんはすでにMFAについてご存知だと思いますので、詳しい説明は省きますが、簡単に言えば、パスワードに重ねて使用する異なる要素の組み合わせです。例えば、PINのような「知っているもの」、携帯電話やセキュリティキーのような「持っているもの」、あるいは生体認証のような「その人自身の特徴」（これは固有性とも呼ばれます）などです。これはAWS IAMのセキュリティベストプラクティスの一つであり、私たちが確認したところによると、MFAは最も一般的な攻撃タイプの一つであるパスワード関連の攻撃の99%以上を防止できます。さらに素晴らしいことに、AWSではMFAを追加費用なしで利用できます。
Central Management for Root User Accessの紹介
MFAについて、そしてMFAを取り巻く戦略の変化や組織全体でどのように活用できるかについて、もう少し詳しくお話ししていきますが、その前に、これらのデバイスと認証情報を管理するための新機能について、Jasonに説明してもらいましょう。ありがとう、Aaron。この新機能の説明に入る前に、少し過去を振り返ってみましょう。これは2006年当時のAWSのログインページです。当時の世界はもっとシンプルで、AWSアカウントを作成すると、ユーザー名とパスワードを設定するオプションが与えられ、それがそのアカウントのRoot userの認証情報となっていました。
お客様のインフラの複雑さが増すにつれて、私たちも共に進化してきました。2011年には、Identity and Access Management（IAM）サービスを導入しました。これにより、お客様は複数のユーザーや複数のRoleを作成し、きめ細かな権限を持つさまざまなPolicyを割り当てることができるようになりました。これによって、お客様は拡大するインフラに合わせて成長しながら、クラウドインフラのセキュリティレベルを高く保つことができるようになりました。これが、今日皆さんが使用しているIAMです。
お客様のクラウドジャーニーを時系列で見ると、複雑さとコンピューティングリソースが徐々に増えていきます。最初は数台のコンピュートノードとストレージ、いくつかのS3バケットを持つ単一のワークロードから始まるかもしれません。インフラの規模と複雑さが増すにつれて、より多くのワークロードやアカウントが追加されていきます。AWSのベストプラクティスの一つは、セキュリティ態勢を強化するためにアカウント分離機能を使用することです。お客様はこのベストプラクティスを積極的に採用し、クラウドの規模とインフラを拡大するにつれて、数百、場合によっては数千のAWSアカウントを持つようになりました。そこでは、大規模なガバナンス、コンプライアンス、その他の機能が必要となります。
2017年には、お客様と共に成長を続け、AWS Organizationsを導入しました。ここにいる多くの方々が使用されているでしょうが、Control Towerと共に、セキュアバイデフォルトな構成を持つLanding Zoneの作成を可能にしました。これにより、すべてのAWSアカウントを一箇所で一元的に管理・統制できるようになり、さらにお客様は効率的にスケールアップしながら、セキュリティ態勢を向上させるセキュアバイデザインのアカウント分離を活用できるようになりました。
それらのアカウントのそれぞれには、2006年当時のオリジナルのログインページに遡る独自のRoot userが存在します。
2024年の現在、Aaronが言及したように、AWSアカウントで最も権限の高いユーザーに対して、単純なユーザー名とパスワードだけでは十分ではなくなりました。AWS Organizationを見てみると、それぞれのアカウントには独自のMFAデバイスが関連付けられています。私の机の上にあるものを何枚か写真に撮りましたが、この組織を構築する際、各アカウントには独自のMFAデバイスが必要になります。お客様の中には3,000のアカウントを持つところもあります。AWS Organizationsを開始した当初は5,000アカウントという制限がありましたが、現在ではこのツールで管理できるアカウント数は10,000まで増加し、実際にそれだけの数のアカウントを持つお客様も出てきています。このような規模でアカウントを管理することは、かなりの負担になることは想像に難くありません。
しかし、2011年に、ユーザーに対して範囲を限定したポリシーと細かなアクセス制御を作成できるIAMという素晴らしい機能を導入したとお話ししました。それでもなお、このRoot userは存在していますが、これは何のために使用されているのでしょうか？調査してみると、Root userのみが実行できるアクションは約10個あることがわかりました。お客様との対話を通じて、これらの10個ほどのアクションの使用頻度を分類すると、それは一つのスペクトラムとして存在することがわかりました。組織の存続期間中に1回、もしくはアカウントごとに1回程度しか実行しないものがあります。例えば、アカウントの閉鎖、AWS GovCloudへの登録（該当する場合）、Marketplaceの販売者としての登録などです。これらは非常に頻度の低いアクションです。
中間的なものとしては、アカウント名や連絡先の詳細、関連付けられたメールアドレスの変更などがあります。しかし、私たちが発見したのは、お客様がよく行う必要があり、かつRoot userを必要とするアクションが2、3個あるということでした。ここで舞台上で告白させていただきますが、私自身もS3バケットからロックアウトしてしまった経験があります。特に最小権限への移行を進める中では、これはよくある出来事です。ミスを犯すこともありますが、それは問題ありません。お客様にとってより簡単にできるようにすべきだと考え、より摩擦の少ない方法を作成することにしました。
本日、私は誇りを持って新機能「Central Management for Root User Access」を発表させていただきます。これは、AWS OrganizationsとControl Towerで使用できる新しいメカニズムで、AWS組織内のメンバーアカウントへの高権限アクセスを管理、保護、制御することができます。この機能には2つの主要なコンポーネントがあります。1つ目は、メンバーAWSアカウントのRoot userクレデンシャルを一元的に有効化・無効化できることです。この機能を有効にしてメンバーアカウントのRoot userクレデンシャルを無効にすることで、実際にアカウントのセキュリティ表面積を減らすことができます。なぜなら、Root userとしてログインする方法が完全になくなるからです。2つ目は、メンバーAWSアカウント内の特定の権限の必要なアクションを、中央の場所から実行する方法を提供することです。
新機能のデモンストレーションと実装の詳細
そしてもちろん、すべてのAWSサービスと同様に、これらすべてを監査と可視性のレイヤーで包み込んでいます。これにより、インフラ全体を一目で確認し、アカウントの状態とその所在を把握することができます。実際にConsoleで見てみましょう。AWS Organizationsの管理アカウントにログインしてIAM Consoleを開くと、左側に新しいタブが表示されます。
この新しいタブは「Root Access Management」と表示されています。クリックすると、この機能の概要を説明する画面が表示されます。「Enable」をクリックすると、次の画面に進みます。ここでは、先ほど説明した2つの主要な機能、つまりRootアクセスの認証情報の有効化・無効化と、メンバーアカウント内での特権アクションの実行を有効にすることができます。両方を同時に有効にする必要はなく、どちらか一方だけでも構いません。ただ、この機能を使ってみると、きっと両方を有効にして、後戻りしたくなくなると思います。
次に必要なのは、Delegated Adminアカウントの設定です。AWS Organizations管理アカウントに日常的にログインしないようにするのがベストプラクティスです。既存のセキュリティ用のDelegated Administratorアカウントや、その他の特権アカウントを使用することができます。そのアカウントIDを入力することで、AWS Organizations管理アカウントにログインする代わりに、そのアカウントでこれらのアクションを実行できるようになります。有効化すると、AWSでいう「Two-way Door」になります。つまり、必要に応じて後から無効化することもできます。繰り返しになりますが、この機能を使ってセキュリティ上の攻撃対象領域が減少するのを実感すると、きっとその価値がわかるはずです。これらの機能は個別に有効・無効を切り替えることができ、必要に応じてDelegated Adminアカウントを後から変更することも可能です。
先ほど説明した3つの機能について、監査と可視性から見ていきましょう。機能を有効にした後、IAM ConsoleにログインしてRoot Access Managementをクリックすると、この画面が表示されます。ここでは、Organizational Unit別に分類されたAWS Organization全体の概要が表示されます。各アカウントについて、Rootユーザーの認証情報が有効になっているかどうかが一目でわかります。右側に、Rootユーザーとしてログインできるアカウントには「Present」と表示され、Rootユーザーが完全に無効化されているアカウントには緑のチェックマークと共に「Not Present」と表示されます。「Present」ステータスにカーソルを合わせてクリックすると、現在有効になっているRootユーザーの認証情報の詳細が表示されます。アクセスキー、Consoleログイン用の認証情報、署名証明書、MFAデバイスなどの状態がわかります。
例えば、私のような開発者が、制限の厳しすぎるS3バケットポリシーによって自分のS3バケットにアクセスできなくなってしまった場合を考えてみましょう。この機能を使えば、Delegated Adminアカウントにログインし、対象のメンバーアカウントで特権アクションを実行することができます。ポリシーを削除したいS3バケットを選択する画面が表示され、バケットとポリシーを確認できます。バケットポリシーの削除ボタンをクリックするだけで完了です。もうRootユーザーとしてログインする必要も、Rootの認証情報を持っている人を探す必要も、Rootアカウントを保護するために使用していたMFAデバイスを探す必要もありません。
何らかの理由でRoot userにアクセスする必要がある場合や、今回のように完全にRoot userの認証情報を削除したい場合について説明します。後のスライドで各アカウントの状態について詳しく見ていきますが、この機能の使用を開始すると、メンバーアカウントには最初に設定したRoot userの認証情報が存在している状態です。そこで、メンバーアカウントのRoot user認証情報を削除する作業を行います。これはコンソールまたはAPIを通じて実行できます。クリックして進むと、「Delete root user credentials」オプションが表示されます。ここではコンソールパスワードとアクセスキーの最終使用時刻が確認できます。「Delete root user credentials」をクリックすると、そのメンバーアカウントはRoot userを持たない状態になります。
このメンバーアカウントにはもはやRoot userが存在しません。Root userとしてログインすることはできず、この機能を通じて再度有効化しない限り、Root userとしてのアクセスは不可能です。 既存のAWSメンバーアカウントは、Root user認証情報が存在している状態か、あるいは多くの方々がベストプラクティスに従って何千ものRoot userにランダムなパスワードを設定して破棄している状態のいずれかです。後者の場合、通常のログインはできず、Root userアカウントのリカバリーメカニズムを使用して新しいパスワードを作成する必要があります。
この新機能で導入されたのが、右下に示される新しい状態です。これこそが、私たちが推奨するセキュアバイデフォルトの理想的な状態です。つまり、メンバーアカウントにRoot user認証情報が一切存在しない状態です。この状態への移行は非常にシンプルで、Delegated administratorアカウントにログインし、認証情報を削除したいメンバーアカウントを見つけてボタンをクリックするだけです。 もし、SQSやS3バケットポリシーの削除など、ポリシーでカバーされていないRoot userのみが実行できるアクションが必要になった場合でも、いつでも再有効化が可能です。パスワードリカバリーを有効にすると、パスワードリカバリーメカニズムを使用してRoot user認証情報（ユーザー名とパスワード）を作成し、MFAデバイスを設定してRoot userとしてログインし、必要なアクションを実行した後、再度Root user認証情報を削除するサイクルを実行できます。
この機能の最も優れている点は、有効化すると新規メンバーアカウントがデフォルトでこのセキュアな状態になることです。つまり、AWS Organizationsで作成される新しいメンバーアカウントには、最初からRoot user認証情報が一切存在しない状態で作成されます。 これらの操作はすべてコンソールで可能ですが、大規模な運用では APIを使用してスクリプト化する方が効率的です。新しく導入された「STS AssumeRoot」APIを使用すると、厳密に範囲を定めたポリシーを使用してこれらの管理アクションを実行できます。特定のアクションに限定された時間制限付きのSTSトークンを取得できます。例として、S3バケットやS3バケットポリシーの削除のためのポリシーが示されており、すべてのアクセスはAWS CloudTrailを通じてログに記録され、既存のSCPやリソース制御ポリシーによって管理されます。
この機能の委任について、シンプルなアーキテクチャを見てみましょう。例えば、開発者がSlackやTeamsのようなチャットインターフェースを通じて、誤って設定したバケットポリシーを自動的に修正する必要がある場合を考えてみましょう。その仕組みは次のとおりです：ユーザーはAWS Chatbotを通じてDelegated securityアカウントのLambda関数と通信します。承認プロセスを経て、承認されると、Lambda関数は新しいSTS AssumeRoot APIを呼び出します。 そして、特定のバケットのバケットポリシーを削除するための時間制限付き認証情報を受け取り、変更を実行し、修正が完了したことをユーザーに通知します。
この機能の最も素晴らしい点は、Secure by defaultとSecure by designの考え方に沿って、追加料金なしで世界中で利用できることです。私たちは、お客様に可能な限り低コストで最高のセキュリティを提供することが非常に重要だと考えています。 ベストプラクティスとしては、まず機能を有効にすることです。AWS Organizationsの管理アカウントにログインし、Root アクセスを一元管理するためのこの機能を有効にしてください。 次に、それらのアクションを実行できるアカウントを委任し、もちろん最小権限の原則を適用します。これらのアクションには、メンバーアカウントから不要なユーザー認証情報をすべて削除することが含まれます。
また、自動化によるスケーリングも重要です。もちろん、まだ1つのRoot ユーザーが残っています。それは、Organizations管理アカウントのRoot ユーザー自身です。そこで、MFAデバイスについてAmazonがどのように基準を引き上げ続けているのか、Erinに説明を譲りたいと思います。
MFAの重要性とPasskeysの導入
ありがとう、Jason。この機能は運用の負担を軽減し、大規模な運用をより効率的にできるため非常に魅力的ですが、私個人としては、セキュリティの大きな進歩という点で最も期待しています。 新しい一元化されたRoot アクセス管理機能を使用して、アカウント全体の認証情報の数とセキュリティの対象範囲を削減すべきです。これにより、それらの認証情報へのMFA追加に関するリスクや、コンプライアンス要件による定期的なパスワード変更の必要性など、さまざまな懸念事項に対処でき、全体として管理すべきパスワードの数を減らすことができます。
Jasonが言ったように、管理アカウントのRoot ユーザーや、維持することを選択したメンバーアカウントのRoot ユーザーなど、保持するパスワードは保護する必要があります。そこで、もう一度MFAについて話を戻しましょう。私たちは、MFAに関する業界標準をすべてサポートしており、誰にでも合うMFAの形態があります。 Virtual authenticatorアプリをサポートしていますが、これは単にサインインに使用できるアプリコードを生成する時間ベースのワンタイムパスワードです。多くのお客様は、ユーザーに追加のハードウェアを提供する必要がなく、モバイルデバイスやコンピュータに単にアプリをダウンロードするだけで済むため、これを好んでいます。ハードウェアの形態を好む場合は、ハードウェアトークンで全く同じ機能を利用できます。
最後に私のお気に入りは、FIDO2 Passkeysです。FIDO2 Passkeysは、現在の業界における認証の金字塔であり、いくつかの理由で最も推奨されるMFAの形態です。ログイン用の暗号化された鍵ペアを作成するために公開鍵基盤を使用するなど、他のMFAよりも優れたセキュリティ特性を持っています。また、Domain-boundであることが非常に重要で、これは認証情報が登録されたドメインでのみ使用できることを意味し、フィッシング耐性を持っています。
歴史的に、FIDO2デバイスはYubiKeyやTali keyなどのハードウェアベースのセキュリティキーでした。その後、Windows Hello、Apple Touch ID、そして世界中の何十億台ものデバイスに組み込まれたプラットフォーム認証機能として実装されるようになりました。最近では、FIDO2はパスキーのリリースを発表しました。これはクラウドに同期でき、バックアップや復元が可能なFIDO2クレデンシャルです。パスキーについて聞いたことがある方はいらっしゃいますか？うなずいている方が見えますね。素晴らしいことです。私はFIDOと密接に仕事をしていますが、もし1年半前にこの講演をしていたら、このようなうなずきは見られなかったでしょう。これは、プラットフォーム各社がパスキーを日常的に使いやすくするために尽力してきた成果だと思います。
AWS MFAファミリーの最新メンバーであるパスキーについて、詳しく見ていきましょう。FIDO2とパスキーの違いについて、多くの質問を受けます。また、FIDO2とパスキーのどちらを使うべきかと尋ねられることもあります。良いニュースは、選択する必要がないということです。なぜなら、パスキーはFIDO2そのものだからです。ハードウェアセキュリティキーと同じ基本的なセキュリティ保証を維持しながら、バックアップ、復元、他のデバイスへの同期が可能という利点が加わっています。依然として暗号的に安全で、ドメインバインドされており、フィッシング耐性があり、一部のパスキーはデバイスバインドすることも可能です。Windowsを使用している場合、デバイスバインドされたパスキーを作成して、そのハードウェアにのみ集中的に配置することもできます。そして、これらは依然としてMFAのゴールドスタンダードであり続けています。
同期パスキーと呼ばれるものについて、いくつかの変更点があります。多くの新規ユーザーにとって、FIDO2が初めて実用的になったのです。私は日常的にハードウェアセキュリティキーを使用してAWSで使用する様々なサービスやシステムにログインしています。実は今日もYubiKeyのイヤリングをつけていて、はい、これは本物のYubiKeyです。しかし多くの人にとって、デバイスのバックアップができず、必要な時にアクセスできないことは致命的な問題でした。私はとても不器用な人間なので、もしニューヨークの自宅で下水道の格子にセキュリティキーを落としてしまい、他の登録済みキーを持っていなければ、非常に面倒なアカウント回復シナリオに直面することになります。
しかし、パスキーではそのような心配はありません。iCloudやGoogleパスワードマネージャー、Windowsの同等機能に保存されたクレデンシャルを使用して、新しいデバイスを簡単に設定できるからです。これは地理的に分散したチームにとっても役立ちます。緊急時に深夜3時にセキュリティガードを起こす必要もありませんし、Jasonが言及していたように、Root userに登録した1つのMFAキーを探し出す必要もありません。そして、クレデンシャル交換プロトコルのような機能により、パスキーのポータビリティはさらに向上し、異なるプロバイダー間でクレデンシャルを移行できるようになるため、特定のプロバイダーにロックインされる心配もありません。
ただし、この話題を終える前に重要な注意点があります。これはすべての人のセキュリティモデルに適合するわけではありません。個人のデバイスにクレデンシャルをバックアップしたり同期したりすることが望ましくないセキュリティモデルをお持ちの場合は、YubiKeyやTali keyなどのハードウェア形式を検討する必要があるかもしれません。しかし多くの人にとって、これこそが使いやすさとセキュリティの理想的な接点となるのです。
皆さんの多くがPasskeyについて知っていると頷いているのを見かけますが、AWSでの動作を簡単にデモンストレーションしたいと思います。とてもシンプルですよ。Passkeyの登録から、サインインの体験、そして特別なフローであるクロスデバイス認証まで、3つの異なるフローをお見せします。まず、Google Chromeのおかげでルートサインインページに私のユーザー名が既に入力されています。複雑なパスワードも既に保存されており、コンソールのホームページに移動したら、右上のセキュリティ認証情報のドロップダウンメニューを開きます。コンソールは親切にも、ベストプラクティスであるMFAが未登録であることを知らせてくれます。そこで、MFAデバイスを割り当てられる場所までスクロールしていきます。
レジリエンシーのために複数の異なるMFAを登録することを想定して、このPasskeyにニックネームを付けます。そしてPasskeyセキュリティキーを選択します。次に、Touch IDを使用してPasskeyを保存するかどうかを尋ねるブラウザウィンドウが表示されます。Touch IDでサインインできるようになりますよ。そこでTouch IDに触れると、数秒で完了です。これで、フィッシング耐性のある強力な多要素認証により、アカウントのセキュリティ態勢が大幅に向上しました。
では、このPasskeyを使用したサインイン体験も素早くお見せしましょう。同様に、メールアドレスを入力して、既に保存されているパスワードでサインインします。Passkeyを使用するかどうか尋ねられるので、Touch IDに触れると、タップ一つでアカウントにアクセスでき、コンソールに進むことができます。ここで、Passkeyを保存したデバイスが手元にない場合や、新しいラップトップを使用している場合などはどうなるのか気になるかもしれません。そのような場合のために、Passkeyを登録した他のデバイスを持っていれば使用できる、クロスデバイス認証という3つ目のフローがあります。
例えば、iPhoneは手元にあるけれど、Passkeyを登録していないMacを使用している場合を見てみましょう。もう一度サインインすると、このデバイスにPasskeyが保存されているため、このような画面が表示されます。しかし、保存されていない場合は、スマートフォンやタブレット、セキュリティキーを使用するなど、他のサインインオプションが表示されます。スマートフォンを選択すると、QRコードが表示され、それを私のスマートフォンでスキャンします。これは単なるQRコードの読み取りではなく、Bluetoothと近接検知を使用して、実際にPasskeyデバイスの近くにいることを確認します。スマートフォンでは、そのPasskeyを使用してサインインするかどうか、そしてiPhoneで私が設定している生体認証であるFace IDを使用するかどうかを確認されます。
続行を選択すると、顔をスキャンして、これで完了です。サインインできました。先ほどのデモデバイスにPasskeyが保存されていなかった場合は、新しいPasskeyをそのデバイスに保存するかどうかも尋ねられます。これはiPhoneをWindowsデバイスで使用する場合でも、他のAppleデバイスで使用する場合でも機能します。プラットフォーム各社は、この1年間、オペレーティングシステムやブラウザ間の相互運用性の向上に懸命に取り組んできました。
AWSにおけるMFA強制適用プログラムの展開
私個人的には FIDO2 認証の大ファンなのですが、ここで強調しておきたいのは、どのような MFA であっても、MFA を全く使用しないよりは常に優れているということです。もし何らかの理由で、組織が現時点で FIDO2 のような認証方式を採用する準備が整っていない、あるいは採用できない場合でも、パスワードのみの認証よりは、仮想認証アプリのようなものを使用する方がはるかに良い選択となります。では、なぜ今日これほど MFA について時間を割いて話しているのでしょうか？それは、MFA がセキュリティの基本的なベストプラクティスだからです。先ほど MFA の有効性を示すデータをご紹介しましたが、その効果が実証されているにもかかわらず、
業界全体で見ると、MFA のユーザーオプトイン率は依然として低く、私たちが期待する水準を下回っています。これは、アカウント侵害とそれに伴うビジネス上および人的な影響を完全に防げるはずなのに、という状況につながっています。継続的な進化の過程で、そして Secure by Design の観点から、私たちは AWS を見直し、昨年、MFA はもはやデフォルトの体験であるべきだと判断しました。MFA を必須にする時期が来たと判断したのです。ただし、お客様に混乱を招くことなく、前向きな変更として受け入れていただけるよう、細心の注意を払いました。
このプログラムは段階的に実施されており、簡単にご説明させていただきます。皆様の組織がこの journey のどの段階にあるのかを把握する参考になるかもしれません。まず、Steve Schmidt が 2023 年 10 月にブログ記事を投稿し、MFA の強制適用を開始することと、その大まかなタイムラインを公表することから始めました。そして 2024 年 5 月 16 日、私たちのエコシステムの中で最大規模の企業から始めて、AWS Organizations の管理アカウントの一部の Root ユーザーに対して MFA の強制適用を開始しました。
6 月には、この変更をスムーズに受け入れていただくことに重点を置きました。Organizations 外で運用している単独のアカウント、個人開発者、趣味で使用している方々は、セキュリティと使いやすさのトレードオフについて異なる視点をお持ちかもしれないと予想していました。使いやすい MFA オプションの提供を確実にすることを重視し、プログラムの拡大に先立って、第二認証要素として Passkeys を導入することを必須条件としました。reinforce では、FIDO2 Passkeys を第二認証要素として導入したことを発表すると同時に、MFA プログラムを単独アカウントにも拡大したことを発表しました。
まだオプトインしていない方は、ベストプラクティスに従って頻繁にサインインしないようにしているため、このページをまだご覧になっていないかもしれませんが、実際のユーザー体験を簡単にご紹介させていただきます。対象となるアカウントで強制適用が開始されると、初回サインイン時に「アカウントに MFA が設定されていません。MFA は必須です」という通知が表示されます。その場で、現在サポートしているいずれかの MFA 形式を登録するオプションが提供されます。Root アカウントに頻繁にアクセスしない方、例えば緊急時の対応のために使用する方にとって混乱を招く可能性を考慮し、35 日間の猶予期間を設けました。この体験を最大 35 日間スキップすることができますが、その期間が終了すると、マネジメントコンソールに進む前に MFA をアカウントに追加する必要があります。
このプログラムについて、私たちは非常に心強いデータを得ており、それを皆様と共有したいと思います。特に、お客様のエコシステムで同様の課題に直面している方々、つまり顧客基盤を見てMFAが問題を解決すると考えているものの、必須要件とすることに不安を感じている方々にとって参考になるかもしれません。朗報として、しっかりとしたChange Managementとコミュニケーションプランがあれば、業務を妨げることなく、お客様の成功につながる形でこれを実現できるということです。4月から10月の間だけでも、75万人以上のお客様が新たにMFAを有効化し、以前より大幅にセキュリティ態勢を改善することができました。6月にFIDO2 Passkeysのサポートを開始して以来、FIDO2ベースの認証を選択するお客様が100%以上増加しています。
次のステージはまだ完了していませんが、計画が非常に重要です。キャンペーンを計画する際、私たちはお客様がビジネスの中断なく成功するために必要な依存関係を理解しようと努めました。そのため、プログラムをさらに拡大する前に、Central Root Access Management機能のリリースを優先しました。大規模な環境でこれらの高い権限を持つ認証情報を管理しやすくするための追加ツールが必要だという、お客様からのフィードバックに応えたのです。2025年春から、Member AccountsでCentral Root Management機能を使用して認証情報を削除していない場合、MFAが必須となります。この推奨される方法を使用すれば、何百何千ものMember AccountsにMFAを追加するよりもはるかに簡単な方法となります。
本日のまとめとして - 私は本当にパスワードが好きではありません。パスワードだけでは安全性が低く、もはや唯一の認証方法として使用すべきではありません。環境内で管理する必要のあるパスワードの総数を減らすために、Central Root Access Managementを絶対に使用すべきです。残りのパスワードに対するMFAは、不正アクセスを防ぐための非常に効果的な制御であり、AWSにおけるMFA要件の今後の変更に備えておく必要があります。セッションについて質問がある場合は、このあと廊下で引き続きディスカッションができます。本日の時間は以上です。ご清聴ありがとうございました。Reinforceでお会いできることを楽しみにしています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion