垣見です。
IAMのベストプラクティスとしてよく聞く「MFA有効化」は自動処理ワークロード用のIAMユーザーには適用するべきなのか気になって調査した結果、「そもそもIAMユーザーではなくIAMロールを使うべし」という結論になりました。
はじめに
「IAMユーザーに対してMFA（多要素認証、Multi-Factor Authentication）を有効化する」というのはIAMのベストプラクティスとして良く知られているかと思います。
では、例えば定期スクリプトのように、自動処理ワークロードの場合はどうなるでしょうか？
IAMユーザーを作って、アクセスキーを払い出して……あれ？MFAを有効化したらワークロードが動かないんじゃ……？
自動化できるの？それともMFAは未有効化？その場合、セキュリティは大丈夫？
そんな疑問に答えるブログです。
自分が同じ疑問を持って社内で質問したところ、数々のベテラン社員からお答えいただきました。自分で留めておくのはもったいないと思ったのでブログにします。
用語
※これ以降、「ワークロード」という表記はすべて自動処理ワークロードを指します。
- ワークロード：「アプリケーションやバックエンドプロセスなど、ビジネス価値を提供するリソースやコードの集合体」という AWS公式 の定義をお借りし、いくつか条件を加えています。今回の場合、ユーザーが開発するアプリケーションと、ユーザーがAWSと連携して使用する3rdParty製アプリケーションの両方を含んでいます。最初の設定が済んだら長期間自動で動くプログラムを想定しており、都度人間が認証処理を行うような処理はここに含まれません。
- 人的ユーザー：自動処理ワークロードの対の概念。同上公式定義は「人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります」です。
ちなみに、ある1つのIAMユーザーを使うプログラムに人間がリアルタイムの操作・入力（MFAデバイス操作含む）を加えた場合、これは「自動処理ワークロードに人的ユーザーが操作を行った」ということになると解釈しています。
結論
「自動処理ワークロード用IAMユーザーにMFAを有効化すべきか？」→基本必要ありません。
- まずは、IAMユーザーを使わないでIAMロールまたはIAM Roles Anywhereを使えないか検討します。
- 自動処理ワークロード用IAMユーザーを使う必要がある場合、MFAを有効化することはまずありません。
※これはあくまで指標の一つであり、対応の人的コストや社内方針、またどの程度の権限・重要性を持つワークロードなのかのリスク等々のバランスにより、どのレベルまでセキュリティを実装するかは変わってきます。
MFA有効化はIAMユーザーのベストプラクティスである
まず、IAMのドキュメントを見てみましょう。
IAMユーザーにはMFAを設定することがベストプラクティスとして推奨されています。
人的IDとワークロードに対して、MFAを義務付けることはIAMのベストプラクティスです。
Require multi-factor authentication (MFA)
We recommend using IAM roles for human users and workloads that access your AWS resources so that they use temporary credentials. However, for scenarios in which you need an IAM user or root user in your account, require MFA for additional security.
多要素認証 (MFA) を必須とする
AWS リソースにアクセスする人間のユーザーとワークロードの IAM ロールを使用して、一時的な認証情報を使用することをお勧めします。ただし、アカウントに IAM ユーザー またはルートユーザーが必要なシナリオでは、セキュリティを強化するために MFA が必要になります。
AWS Well-Architected フレームワークのセキュリティの柱にも、MFAを有効化することが有効だと書いてありますね。
サインイン (サインイン認証情報を使った認証) は、多要素認証 (MFA) などのメカニズムを使わない場合、特にサインイン認証情報が不用意に開示されたり、容易に推測されたりする場合に、リスクが発生する恐れがあります。MFA や強力なパスワードポリシーを要求することで、これらのリスクを軽減する強力なサインインのメカニズムを使用します。
ということで、IAMユーザーを使う場合はMFAを有効化すべきというのがベストプラクティスのひとつだということがわかりました。
IAMロールを使いましょう
IAMユーザーよりもIAMロールが推奨される
ところで先ほどの記述、少し気になりませんか？
「However」「ただし」の前では「IAMロールを使って一時的な認証情報を使え」とあります。
Require multi-factor authentication (MFA)
We recommend using IAM roles for human users and workloads that access your AWS resources so that they use temporary credentials. However,for scenarios in which you need an IAM user or root user in your account, require MFA for additional security.
多要素認証 (MFA) を必須とする
AWS リソースにアクセスする人間のユーザーとワークロードの IAM ロールを使用して、一時的な認証情報を使用することをお勧めします。ただし、アカウントに IAM ユーザー またはルートユーザーが必要なシナリオでは、セキュリティを強化するために MFA が必要になります。
IAMユーザーの場合はMFA有効化が望ましいけれど、そもそものおすすめはIAMロールだと書いてありますね。
はい、そうなのです。
セキュリティ向上の観点から、AWSはそもそもIAMユーザーではなく、IAMロールやIAM Roles Anywhereの使用を推奨しています。
AWS 内でアクセス権を管理する場合、IAM ユーザーは一般に最良の選択肢ではありません。ほぼどんなユースケースでも IAM ユーザーを利用しないことをお勧めします。
（中略）
以下のリストは、AWS の IAM ユーザーとの長期認証情報が必要な特定のユースケースを示しています。IAM を使用して自分の AWS アカウントの下にこれらの IAM ユーザーを作成し、そのユーザーのアクセス許可を IAM で管理できます。
- AWS アカウントに対する緊急アクセス
- IAM ロールを使用できないワークロード
- AWS CodeCommit アクセス
- Amazon Keyspaces (Apache Cassandra 向け) のアクセス
- サードパーティーの AWS クライアント
- アカウントで AWS IAM Identity Center を利用できず、他に ID プロバイダーがない場合
結構な言いようですね。
頼りになりすぎる社内有識者によると、「最近のSaaSあたりはIAMロール前提になってるので、IAMロールを基本的にはマストとしてロールが使えないサービスは可能な限り避けるようにしたほうが良い」とのお言葉をいただきました。
AWSのベストプラクティスに合わせ、最近は3rdParty製品側がIAMユーザーのクレデンシャルを使う形からIAMロールを使えるようにする動きがあるそうですね。（全ての3rdParty製品がそうという訳ではないです）
もちろん弊社のAWS運用自動化アプリ、Cloud AutomatorはIAMロールに対応しております。（宣伝） blog.serverworks.co.jp
IAMユーザーは長期的な認証情報
IAMユーザーのアクセスキーを使った接続は一時的な認証情報ではなく、アクセスキー・シークレットアクセスキーがどこかで漏れたらそのまま使われてしまう脆弱性を持っています。（だからこそMFAを使うわけです）
これはAWS Well-Architected フレームワーク セキュリティの柱の別の章でも言われていますね。
一般的なアンチパターン: （中略） 一時的認証情報を使用できるのに、マシン ID に対して長期的なアクセスキーを使用する。 参考：SEC02-BP02 一時的な認証情報を使用する
私はこのあたりも良くわかっていなかったのですが、公式ドキュメントを読み解くと「なるほど」と思います。
AWS IAM Roles Anywhereという選択肢
また、オンプレミスのバッチサーバ等でIAM ロールを直接は使えない！と言った場合、AWS IAM Roles Anywhereを利用することもできるそうです。
AWS IAM Roles Anywhere を使うと、オンプレミスなどAWS外部のサーバーに、AWS環境からアクセスキーやシークレットアクセスキーを払い出す必要がなくなり、オンプレミスなどAWS外部のサーバー上で発行し保管している秘密鍵で AWS の API を実行できるようになります。こちらも「一時的な認証情報」に該当しますので、ご検討ください。
ただし実装するかどうかは場合に応じて都度選択するべき
ただし、「既存のワークロードを改修するほどのコストはかけられない」「使いたい3rdParty製品がIAMロールに対応していない」というような場合もあるかと思います。
もちろんベストプラクティスは必ず添わなければいけないというものではないので、そのような取捨選択をすることも許容されています。（むしろこの柔軟性と判断すること自体が大事です）
そんな場合は「ワークロード用IAMユーザーとMFA」の関係を考える必要があります。
MFAを有効化すべき？
自動処理ワークロード用IAMユーザーにはMFAは有効化しない
ようやくこのブログの原点に戻ってきました。結論はこの章題のとおりです。
ワークロード用のIAMユーザーには、MFAを有効化するようなことはまずないと言って良いみたいです。
ワークロード向けに発行したIAMユーザーに対してもMFAを割り当て、MFA入力を必須化すること自体は可能です。なお、IAMユーザーに割り当てるポリシー内で "aws:MultiFactorAuthPresent": "true" のように設定する必要があります。（豆知識）
参考：MFA を使用した安全な API アクセス
しかし、アプリケーション内でMFAを自動的に入力させることはできないため、プログラム用IAMユーザーでMFAを適用するのは現実的ではありません。
もしアプリケーションで使うIAMユーザーにMFAを適用する場合、ワークロードに対して人間が定期的にMFAの値を入力してあげるように実装してある必要が出てきます。「都度申請して一時的に動かす」というような形ですね。
「人的ユーザーの処理に依存している」という、単純な自動ワークロードとは別の状態だととらえて考えるとわかりやすいかと思います。
要件を満たせばこれもまた選択肢ですが、要件によってはそれができない場合もあります。誰も定期処理でMFAを都度入力なんてしたくないですよね。
ちなみにMFAの要求間隔はある程度伸ばせるそうです。 blog.serverworks.co.jp
そのため、定期実行のような「ワークロード」に対しては、MFAは有効化しなくて良い……というか、実質的に「できない」となるわけです。
実際、自動処理のワークロードでMFAを導入しているお客様はほぼいないと言い切れるようでした。
MFAなしでセキュリティは大丈夫なのか？
結論としては、「MFA以外のところで気を付ければ確率は下がる」「場合による」です。自分で議題にしておきながら、しまりの悪い感じになってしまい恐縮です。
当たり前ですが、セキュリティというのはどこまでやるかと言われたら無限にできてしまうものです。「大丈夫」と言い切るのはなかなか難しいものです。
しかも攻撃を受けるかどうかは未知、ある種の運もあるので保険のように成果がわかりにくいときました。
現実的に請求・運用管理コストなどを想定リスクと費用対効果で比べ、組み合わせて納得いくラインに落とし込むのが設計のお仕事です。
人的IAMユーザーへのMFAは簡単で効果が高いのと比べて、ワークロード用IMAユーザーに対するMFAというのはセキュリティ向上という目的に対して運用負担が大きく、しかも守りたいはずのワークロードそのものを止めかねないというリスクがあります。
だとしたら、取るべき選択は「他の手段で補う」になってきます。「IAMユーザーを最小権限にしておく」といったベストプラクティスはその一つですね。
MFAはクレデンシャルの一部が漏れたときの対策ですが、漏れてもダメージを抑えるように最小権限にしたり、そもそもAWS外のネットワークの設定で怪しいアクセス元を許可しなかったり、クレデンシャルなどの重要情報が漏れないようにセキュアな保管場所や開発における社内ルールを整備したり、最新のミドルウェアへのアップロード・パッチ当てが済んでない限りは重要なリソースに対してはアクセスを限定したり、各通信を仲介する仮想アプライアンスや通信ログを管理するSIEMやGuardDutyなどで通常と違う通信挙動をしているサーバを検知したり……といった具合です。
こちらのブログはAWSのセキュリティのベストプラクティスをわかりやすくまとめているのでぜひご覧ください。
補足として、先輩に教えてもらってなるほどと思ったことを残しておきます。
人的ユーザーとワークロードの違いとして、「 自社・自組織の安全で信頼された環境下にあるサーバ・プログラミングリソースによる処理か/そうではないか」というのがあり、結果として 「人間の認証は脆弱なポイントが多い」というのがあります。
- パスワードが脆弱になりがち（パスワードを使いまわしたり、推測されやすい安易なパターンをパスワードを設定したり）
- 強制されない限りは同じ内容のものを使いがち
- 脆弱な内容のものでなくても物理的に盗取されるリスクもある（後ろから盗み見られる、離席時にパスワードマネージャーやconfigを見られる）
だから、1つの正しい情報を入力できただけで、正当なアクセスかどうかを判断するのはだいぶ心許ないのです。
しかもアクセス元の条件が変わりうる（利用デバイス、IP、ロケーションetc.）ので、余計に「本当にその人かどうか」を特定させるのが難しい。
それゆえに、アクセスの正当性を確かめるために、生体認証だったりMFAだったりで身元の確認をする必要があるわけです。
いかがでしょうか？自分はすごく学びになりました。MFAは、人間が使うからこそ心もとなくなるセキュリティの一面を補ってくれるような側面もあるのですね。
逆に自動処理ワークロードについては通信先が限定されたリソースから常にアクセスが生じやすいといった特性があるため、MFAではなく別の方面からセキュリティを対策していくのが大事ということです。
結論（再）
「自動処理ワークロード用IAMユーザーにMFAを有効化すべきか？」→基本必要ありません
- まずは、IAMユーザーを使わないでIAMロールまたはIAM Roles Anywhereを使えないか検討します。
- IAMユーザーを使う必要がある場合、MFAを有効化することはまずありません。
※これはあくまで指標の一つであり、対応の人的コストや社内方針、またどの程度の権限・重要性を持つワークロードなのかのリスク等々のバランスにより、どのレベルまでセキュリティを実装するかは変わってきます。
おわりに
知恵をお貸しくださった先輩方、改めてありがとうございました。
このブログが皆様のお役に立てば幸いです。
