前回の続き（4大クラウドのIAM要件トップ10）
前回は、AWS、Azure、GCP、OCIの共通的なIAM要件トップ10および、No.1の多要素認証の導入について説明しました。今回はNo.2～10まで一気に解説します。
4大クラウドのIAM要件トップ10（No.2～10）
No.2 必要最小限の管理者権限
No.2は、必要最小限の管理者権限です。各クラウドサービスにおいて、管理者の権限、もしくはロールには非常に多くの種類があります。管理者権限であってもすべての権限を付与するのではなく、業務上必要な権限範囲のみに限定することが望ましいです。
細かくは以下のサブ要件に分類されます。
- ・必要最小限の管理者権限の付与（※一部レベル2）
- ・最上位管理者アカウントの利用制限
- ・特定の独自ロール作成の制限
- ・アクセス制御機能へのアクセス制限
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| 必要最小限の管理者権限の付与 | AWS 1.16 完全な「*：*」管理者権限を許可するIAMポリシーが付与されていないことを確認する（レベル1･自動化） Azure 1.25 「Azure ADディレクトリに入るサブスクリプション」および「Azure ADディレクトリから出るサブスクリプション」が「誰にも許可しない」に設定されていることを確認する（レベル2･手動） GCP 1.5 サービスアカウントに管理者権限がないことを確認する（レベル1･自動化） GCP 1.6 IAMユーザーにプロジェクトレベルでサービスアカウント利用者またはサービスアカウントトークン作成者ロールが割り当てられていないことを確認する（レベル1･自動化） OCI 1.1 特定サービスのリソースを管理するためにサービスレベルの管理者が作成されていることを確認する（レベル1･手動) OCI 1.2 すべてのリソースに対する権限がテナンシ管理者グループにのみ付与されていることを確認する（レベル1･手動) OCI 1.3 IAM管理者がテナンシ管理者グループを更新できないことを確認する（レベル1･手動) OCI 1.14 ストレージサービスレベルの管理者が、自分が管理するリソースを削除できないようにすることを確認する（レベル2･手動） |
| 最上位管理者アカウントの利用制限 | AWS 1.7 管理および日常のタスクでの「root」ユーザーの使用を排除する（レベル1･自動化） |
| 特定の独自ロール作成の制限 | Azure 1.23 カスタムのサブスクリプション所有者ロールが作成されていないことを確認する（レベル1･自動化） |
| アクセス制御機能へのアクセス制限 | Azure 1.17 [Azure AD管理ポータルへのアクセスを制限する]が[はい]に設定されていることを確認する（レベル1･手動) |
No.３ パスワードポリシーの設定
次はパスワードポリシーの設定です。CIS Benchmarksでは多要素認証が推奨されていますが、パスワードポリシーに関する推奨策も数多く盛り込まれています。なお、CIS Controls（バージョン8）の5.2では多要素認証を使用するアカウントは8文字以上、使用しないアカウントは14文字以上のパスワードを使用することを推奨しています。パスワードをどこまで長くするかは各組織の判断次第となります。
細かくは以下のサブ要件に分類されます。
- ・14文字以上のパスワード長
- ・パスワード再利用の防止
- ・パスワードリセット時の追加確認
- ・不適切なパスワードの禁止
- ・パスワードの再確認
- ・パスワードリセット時の通知
- ・365日以内のパスワード有効期限
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| 14文字以上のパスワード長 | AWS 1.8 IAMパスワードポリシーが、最小14文字以上の長さを要求することを確認する（レベル1･自動化） OCI 1.4 IAMパスワードポリシーが、最小14文字以上の長さを要求することを確認する（レベル1･手動) |
| パスワード再利用の防止 | AWS 1.9 IAMパスワードポリシーがパスワードの再利用を防止していることを確認する（レベル1･自動化） OCI 1.6 IAMパスワードポリシーがパスワードの再利用を防止していることを確認する（レベル1･手動) |
| パスワードリセット時の追加確認 | Azure 1.6 「リセットに必要な認証方法の数」が「2」に設定されていることを確認する（レベル1･手動) |
| 不適切なパスワードの禁止 | Azure 1.7 カスタムの不適切なパスワードリストが組織に対して「強制」に設定されていることを確認する（レベル1･手動) |
| パスワードの再確認 | Azure 1.8 「ユーザーが認証情報の再確認を求められるまでの日数」が「0」に設定されていないことを確認する（レベル1･手動) |
| パスワードリセット時の通知 | Azure 1.9 「パスワードリセットについてユーザーに通知しますか？」が「はい」に設定されていることを確認する（レベル1･手動) Azure 1.10 「他の管理者が自らのパスワードをリセットしたときにすべての管理者に通知しますか？」が「はい」に設定されていることを確認する（レベル1･手動) |
| 365日以内のパスワード有効期限 | OCI 1.5 IAMパスワードポリシーが365日以内にパスワードを期限切れにすることを確認する（レベル1･手動) |
No.4 最小限のその他認証情報
次に最小限のその他認証情報です。通常、認証情報（Credentialsのこと。資格情報ともいう。）といえば一般的にはユーザーIDおよびパスワードをイメージすると思います。しかし、本コラムではユーザーIDおよびパスワード以外の認証情報を「その他認証情報」として取り扱います。例えば、以下のようなものが挙げられます。
- ・アクセスキー：AWSにおいて外部からクラウドサービスへCLIでプログラムアクセスするための認証情報。
- ・APIキー：APIまたはSDKに対して呼び出しを実行したアプケーション等を識別するための認証情報。
- ・サービスアカウント：GCPにおいてアプリケーション等が特定のリソースに対してアクセスするために割り当てられる認証情報。
細かくは以下のサブ要件に分類されます。
- ・管理者むけその他認証情報の制限
- ・ユーザーむけその他認証情報の制限
- ・サービスむけその他認証情報の制限
- ・その他認証情報の使用範囲の制限（※一部レベル2）
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| 管理者むけその他認証情報の制限 | AWS 1.4 rootユーザーアカウントのアクセスキーが存在しないことを確認する（レベル1･自動化） OCI 1.11 テナンシ管理者ユーザー用にAPIキーが作成されていないことを確認する（レベル1･自動化） |
| ユーザーむけその他認証情報の制限 | AWS 1.11 コンソールパスワードを持つすべてのIAMユーザーの初期ユーザーセットアップ中にアクセスキーをセットアップしない（レベル1･手動） AWS 1.13 1人のIAMユーザーが使用できるアクティブなアクセスキーが1つだけであることを確認する（レベル1･自動化） |
| サービスむけその他認証情報の制限 | GCP 1.4 各サービスアカウントにGCP管理のサービスアカウントキーのみが存在することを確認する（1･自動化） |
| その他認証情報の使用範囲の制限 | GCP 1.12 APIキーがプロジェクト用に作成されていないことを確認する（レベル2･手動） GCP 1.13 APIキーが特定のホストおよびアプリのみの使用によって制限されていることを確認する（レベル1･手動) GCP 1.14 APIキーが、アプリケーションがアクセスを必要とするAPIのみに制限されていることを確認する（レベル1･手動) |
No.5 その他認証情報のローテーション
次は、その他認証情報のローテーションです。ローテーションはどれも90日以内とされています。
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| その他認証情報のローテーション | AWS 1.14 アクセスキーが90日以内にローテーションされることを確認する（レベル1･自動化） GCP 1.7 サービスアカウントのユーザー管理キー／外部キーが90日ごとまたはそれ以内にローテーションされることを確認する（レベル1･自動化） GCP 1.15 APIキーが90日ごとにローテーションされることを確認する（レベル1･手動) OCI 1.8 ユーザーのAPIキーが90日以内にローテーションすることを確認する（レベル1･自動化） OCI 1.9 ユーザーのカスタム秘密鍵が90日以内にローテーションすることを確認する（レベル1･自動化） OCI 1.10 ユーザー認証トークンが90日以内にローテーションすることを確認する（レベル1･自動化） |
No.6 グループに基づくアクセス権限設定
次にグループに基づくアクセス権限設定です。各クラウドサービスで、アクセス権限の設定にはグループを使用した方法が推奨されています。
細かくは以下のサブ要件に分類されます。
- ・グループを介したユーザーへのアクセス許可
- ・グループを介したインスタンスなどへのアクセス許可
- ・グループの作成や管理の制限（※レベル２）
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| グループを介したユーザーへのアクセス許可 | AWS 1.15 IAMユーザーがグループを介してのみアクセス許可を受け取ることを確認する（レベル1･自動化） |
| グループを介したインスタンスなどへのアクセス許可 | OCI 1.13 OCIインスタンス、OCIクラウドデータベース、およびOCI FunctionがOCIリソースにアクセスするために動的グループが使用されていることを確認する（レベル1･手動） |
| グループの作成や管理の制限 | Azure 1.18 「アクセス枠におけるグループ機能にアクセスするユーザーの機能を制限する」が「はい」に設定されていることを確認する（レベル2･手動） Azure 1.19 「ユーザーがAzureポータル、API、またはPowerShellでセキュリティグループを作成できる」が「いいえ」に設定されていることを確認する（レベル2･手動） Azure 1.20 「所有者がアクセスパネルでグループメンバーシップリクエストを管理できる」が「いいえ」に設定されていることを確認する（レベル2･手動） Azure 1.21 「ユーザーがAzureポータル、API、またはPowerShellでMicrosoft365グループを作成できる」が「いいえ」に設定されていることを確認する（レベル2･手動） |
No.7 クラウドサービスとの連絡先の維持
次は、クラウドサービスとの連絡先の維持です。セキュリティ上の有事が発生した場合、クラウド側からの連絡を早めに受け付けて対処する必要があります。システム運用管理やインシデントレスポンスの観点からも重要な要件です。
細かくは以下のサブ要件に分類されます。
- ・重要な連絡先の維持
- ・ユーザー連絡先の維持
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| 重要な連絡先の維持 | AWS 1.2 セキュリティ連絡先情報が登録されていることを確認する（レベル1･手動) GCP 1.16 重要な連絡先が組織用に構成されていることを確認する（レベル1･自動化） |
| ユーザー連絡先の維持 | AWS 1.1 現在の連絡先の詳細を維持すること（レベル1･手動） OCI 1.12 すべてのOCIのIAMユーザーアカウントに有効で最新の電子メールアドレスがあることを確認する（レベル1･手動） |
No.8 アプリケーションアクセスの制限
次は、アプリケーションアクセスの制限です。この要件はアプリケーションによるアクセスの制限と、ユーザーによるアプリケーションの利用制限の両方がテーマとなります。
細かくは以下のサブ要件に分類されます。
- ・アプリケーション同意の制限（※一部レベル2）
- ・アプリケーション追加の制限
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| アプリケーション同意の制限 | Azure 1.11 「ユーザーは自分の代わりに会社のデータにアクセスするアプリに同意できる」が「検証済みの発行元を許可する」に設定されていることを確認する（レベル2･手動） Azure 1.12 「ユーザーは自分の代わりに会社のデータにアクセスするアプリに同意できる」が「いいえ」に設定されていることを確認する（レベル1･手動) |
| アプリケーション追加の制限 | Azure 1.13 「ユーザーがギャラリーアプリをマイアプリに追加できる」が「いいえ」に設定されていることを確認する（レベル1･手動） Azure 1.14 「ユーザーがアプリケーションを登録できる」が「いいえ」に設定されていることを確認する（レベル1･手動） |
No.9 アカウントのレビュー
次は、アカウントのレビューです。これは不要なアカウントの把握および無効化を求める要件です。
細かくは以下のサブ要件に分類されます。
- ・ゲストユーザーのレビュー（※一部レベル2）
- ・未使用アカウントの無効化
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| ゲストユーザーのレビュー | Azure 1.3 Azure AD Privileged Identity Managementで外部ユーザーのアクセスレビューが設定されていることを確認する（レベル2･手動） Azure 1.4 ゲストユーザーが毎月レビューされることを確認する（レベル1･手動) |
| 未使用アカウントの無効化 | AWS 1.12 45日以上使用されていない認証情報が無効になっていることを確認する（レベル1･自動化） |
No.10 KMSへのアクセス制御
最後にKMSへのアクセス制御です。KMSとは、Key Management Service（鍵管理サービス）の略で、ファイルなどを暗号化するための暗号鍵の生成、使用、ローテーション、破棄などを行えるサービスです。KMSの暗号鍵へのアクセスは、必要最小限に制限する必要があります。
細かくは以下のサブ要件に分類されます。
- ・KMS暗号鍵へのアクセス制御
- ・KMS暗号鍵のローテーション
CIS Benchmarksにおける推奨策は以下の通りです。（末尾にプロファイル・評価ステータスも記載）
| サブ要件 | IAM推奨策 |
|---|---|
| KMS暗号鍵へのアクセスの制限 | GCP 1.9 Cloud KMS暗号鍵が匿名アクセスまたはパブリックアクセスが可能でないことを確認する（レベル1･自動化） |
| KMS暗号鍵のローテーション | GCP 1.10 KMS暗号鍵が90日以内にローテーションされることを確認する（レベル1･自動化） |
まとめ
繰り返しになりますが、CIS BenchmarksにおけるAWS、Azure、GCP、OCIの共通的なIAM要件トップ10は以下の結果でした。
大まかに以下のようにまとめられます。
- ・No.1、2、3、6、9（多要素認証の導入、管理者権限の最小化、パスワードポリシーの設定、グループに基づくアクセス権限設定、アカウントのレビュー）はIAMにおいてよくある要件です。これはイメージしやすいテーマだと思います。
- ・No.4、5（最小限のその他認証情報、その他認証情報のローテーション）はアクセスキー、APIキー、サービスアカウントなど、ID・パスワード以外の認証情報を対象としており、普段意識しづらいテーマだと思います。認証情報には様々な種類があり、それらにもコントロールが必要であることを示しています。
- ・No.7（クラウドサービスとの連絡先の維持）はIAMの範囲に入るのか少々迷いますが、クラウドサービスとの適切かつスピーディなコネクションを維持することは緊急時への対応にはとても重要です。
- ・No.8、10（アプリケーションアクセスの制限、KMSへのアクセス制御）はアプリケーションおよび鍵管理にもコントロールが必要であることを示しています。
トップ10それぞれのIAM推奨策を見てみると、必ずしも4つすべてのクラウドサービスが含まれているわけではないことが分かります。しかし、これらを一概にクラウドサービスの優劣と決めつけてしまうのではなく、様々なセキュリティ観点を得る手段と考えてセキュリティ設計に活用することが望ましいです。
なお、本コラムの対象はクラウドサービス自体のIAMであるため、その上に構築する仮想マシンやストレージ、データベース、ネットワークなどを対象としたセキュリティ対策は別に検討する必要があるのでご注意ください。
最後になりますが、各クラウドサービスにおいて機能追加は断続的に行われており、CIS Benchmarksもまた不定期にバージョンアップされています。また、クラウド利用企業においても日々、機能追加や変更を加えていることと思います。
そのためクラウドサービスにおいてセキュリティ対策を実装した後も、定期的にその妥当性を確認することが望ましいです。4大クラウドそれぞれが提供するセキュリティ設定診断機能や、専門業者のクラウド設定診断サービスを活用することも有効です。
参考資料
- [1]Center for Internet Security CIS Benchmarks
- [2]CIS「CIS_Amazon_Web_Services_Foundations_Benchmark_v1.5.0」
- [3]CIS「CIS_Microsoft_Azure_Foundations_Benchmark_v1.5.0」
- [4]CIS「CIS_Google_Cloud_Platform_Foundation_Benchmark_v1.3.0」
- [5]CIS「CIS_Oracle_Cloud_Infrastructure_Foundations_Benchmark_v1.1.0」
- [6]CIS「CIS Critical Security Controls® Version 8」
※文章中の商品名、会社名、団体名は、各社の商標または登録商標です。