本文の内容は、2021年8月5日にAlba Ferriが投稿したブログ(https://sysdig.com/blog/securing-aws-iam-with-sysdig-secure）を元に日本語に翻訳・再構成した内容となっております。
昨年のIDCによるクラウドセキュリティ調査では、調査対象となった企業の約80％が、過去18カ月間に少なくとも1件のクラウドデータ侵害を受けていることがわかりました。
クラウドセキュリティの脅威のトップ3は、本番環境のセキュリティの誤設定（67％）、本番環境でのアクセスの可視化不足（64％）、不適切なIAMおよび権限の設定（61％）となっています。
クラウドネイティブセキュリティホワイトペーパーによると、アイデンティティとアクセス管理の項目で、アプリケーションやワークロードが相互認証を用いて通信する際には、明示的に権限を与えるべきだと主張しています。
IAM（Identity and Access Management）とは、誰がどのリソースにアクセスできるかを管理することであり、クラウドセキュリティにおいて非常に重要な役割を担っています。IAMは他のすべてのクラウドサービスと統合されているため、AWSの中でも最も複雑なアーキテクチャの1つとなっています。
AWS IAMのセキュリティの確保が必要な理由
IAMは、任意のIDが適切なリソース（アプリケーション、データベース、ネットワークなど）に、適切なコンテキストでアクセスできることを保証することを目的としています。AWS IAMでは、お客様のクラウドアカウント上のすべての資産を意味します。より明確に言えば、このサービスが悪意のある人の手に渡れば、その人はあなたのクラウドインフラストラクチャー全体にアクセスできることになります。
IAMユーザーとロールのアカウントアクティビティ履歴にアクセスするには、AWS CloudTrailのイベント履歴、Amazon CloudWatchのクエリー、またはAmazon Athenaで照会することができます。
そして、各監査イベントをアクセスコントロールポリシーと比較する必要があります。
クラウドアカウントのユーザー数、アプリケーション数、マイクロサービス数が増えれば増えるほど、発生する情報（イベント）も増え、結果的に木を見て森を見ずになってしまうことに留意してください。
ポリシーでチェックすべき一般的なIAMの誤設定は以下の通りです。
- MFA（多要素認証）が有効になっていない。
- パスワードのベストプラクティスに従っていない。
- 未使用のクレデンシャルを無効にしていない。
- IAMポリシーをグループやロールではなく、ユーザーに取り付けている。
- キーを頻繁に交換していない。
- リソースに適切にアクセスできないEC2インスタンスがある。
- 最小限の権限の原則を適用していない。
- リソースベースのポリシーが定義されたリソースにアタッチされていない。
IAM向けのSysdigアウトオブボックスルール
Sysdig Secureには、EC2ホストインスタンス、Fargateタスク、Elastic Load Balancingサービス、IAMなどのクラウドサービスに関連する多くのルールがすぐに使えるように用意されています。
現在、30種類以上のルールが用意されており、AWSアカウントのセキュリティを向上させたり、IAMの設定が流失しないようにするのに役立ちます。
コンテナやKubernetesのセキュリティルールを作成するのと同じ言語を使うだけで、特定のニーズを満たすために必要な数のルールを追加することができます。
私たちのルールの言語に慣れていない方のために、数ヶ月前にRule Tunerをリリースして、ルールの編集、作成、修正のプロセスをより簡単にしました!
AWS IAM用のSysdig ルールを深掘りする
この記事を書いている時点で、Sysdig Secureで見つけられるAWS IAM用のすぐに使えるルールの完全なセットは以下の通りです。| # | ルール | 説明 | プライオリティ |
| 1 | Add AWS User to Group | ユーザーをグループに追加することを検出 |
INFO |
| 2 | Attach Administrator Policy | 管理者ポリシーのユーザーへのアタッチを検出 |
WARNING |
| 3 | Attach IAM Policy to User | IAM ポリシーのユーザーへのアタッチを検出 |
NOTICE |
| 4 | Create Group | 新しいユーザー グループの作成を検出 |
WARNING |
| 5 | Create Security Group Rule Allowing SSH Ingress | SSH penetrationを許可するセキュリティグループルールの作成を検出 |
ERROR |
| 6 | Create AWS user | 新しい AWS ユーザーの作成を検出 |
INFO |
| 7 | Create IAM Policy that Allows All | すべてを許可する IAM ポリシーの作成を検出 |
CRITICAL |
| 8 | Create Access Key for Root User | ルートユーザーのアクセスキーの作成を検出 |
CRITICAL |
| 9 | Create Security Group Rule Allowing Ingress Open to the World | すべてを許可するイングレスのセキュリティグループルールの作成を検出 |
CRITICAL |
| 10 | Console Login Failure | コンソールログインの失敗を検出 |
WARNING |
| 11 | Console Login Without MFA | MFAを使用しないコンソールログインを検出 |
CRITICAL |
| 12 | Console Root Login Without MFA | MFAを使用しないルートコンソールログインを検出 |
CRITICAL |
| 13 | Deactivate Hardware MFA for Root User | ルートユーザーのハードウェア MFA 設定の無効化を検出 |
CRITICAL |
| 14 | Deactivate MFA for Root User | ルートのMFA設定の無効化を検出 |
CRITICAL |
| 15 | Deactivate Virtual MFA for Root User | ルートの仮想MFA設定の停止を検出 |
CRITICAL |
| 16 | Delete Virtual MFA for Root User | ルートの MFA 設定の削除を検出 |
CRITICAL |
| 17 | Deactivate MFA for User Access | ユーザーアクセス用の MFA 設定の無効化を検出 |
WARNING |
| 18 | Logged in without Using MFA | MFA (multi-factor authentication)を使用せずにユーザーがログインしたことを検出 |
CRITICAL |
| 19 | Delete Group | ユーザーグループの削除を検出 |
WARNING |
| 20 | Password Recovery Requested | AWS IAM のパスワードリカバリー要求を検出 |
WARNING |
| 21 | Put IAM Inline Policy to User | IAM インラインポリシーのユーザーへの適用を検出 |
NOTICE |
| 22 | Put Inline Policy in Group to Allow Access to All Resources | すべてのリソースへのアクセスを許可するグループにインラインポリシーを入れたことを検出 |
WARNING |
| 23 | Root User Executing AWS Command | ルートユーザーがAWSコマンドを実行していることを検出 |
CRITICAL |
| 24 | Update Account Password Policy Not Requiring 14 Characters | 14文字以上の長さを必要としないパスワードポリシーの更新を検出 |
WARNING |
| 25 | Update Account Password Policy Not Requiring 7 Characters | パスワードポリシーを更新する際に、7文字以上の長さを必要としないことを検出 |
WARNING |
| 26 | Update Account Password Policy Expiring in More Than 90 Days | 90日以上経過したパスワードポリシーの更新を検出 |
NOTICE |
| 27 | Update Account Password Policy Not Expiring | 更新するパスワードポリシーの有効期限が設定されていないことを検出 |
NOTICE |
| 28 | Update Account Password Policy Not Preventing Reuse of Last 24 Passwords | パスワードポリシーを更新しても、過去24個のパスワードの再利用が防止されていないことを検出 |
NOTICE |
| 29 | Update Account Password Policy Not Preventing Reuse of Last 4 Passwords | 更新中のパスワードポリシーで、最後の4つのパスワードの再利用を防止していないことを検出 |
WARNING |
| 30 | Update Account Password Policy Not Requiring Lowercase | 小文字の使用を要求していないパスワードポリシーの更新を検出 |
WARNING |
| 31 | Update Account Password Policy Not Requiring Number | パスワードポリシーを更新した際に、数字の使用が要求されていないことを検出 |
WARNING |
| 32 | Update Account Password Policy Not Requiring Symbol | 記号の使用を必要としないパスワードポリシーの更新を検出 |
WARNING |
| 33 | Update Account Password Policy Not Requiring Uppercase | 大文字の使用を必要としないパスワードポリシーの更新を検出 |
WARNING |
| 34 | Update Assume Role Policy | ロールの変更を検出 |
WARNING |
それでは、Sysdig Secure for AWS IAMで提供しているルールの一部を詳しく見ていきましょう。
ルール#8 – rootユーザーのアクセスキーを作成する
待てよ、もっといい方法があるはずだ。
AWSアカウントのルートユーザーがコマンドを実行していることを検知するよりも賢い方法があることをご存知ですか？それは、アクセスキーを持っていないことです。
問題ありません、それも検出します。:)
次に、管理者アクセスが必要な場合は、特定のタスクを担当する各人にIAMユーザーを作成します。
その際、ユーザーを”Administrators”ユーザーグループに入れ、AdministratorAccessマネージドポリシーを添付することを忘れないでください。
ルール#18 – 多要素認証を使わずにログインしている
もう1つの古典的なIAMセキュリティのベストプラクティスは、多要素認証（MFA）を設定することです。MFAは、セキュリティ層を追加することで、悪意のある人が自分であるかのようにログインすることを困難にし、お客様を保護することを目的としています。
もし窃盗犯があなたの認証方法の両方を盗む必要があれば、考え直すかもしれません。
AWSアカウントの各ユーザーにMFA認証を有効にすることは、かなり良い出発点となります。
誰かがMFAなしでログインすると、Sysdigはすぐに警告を発します。
ルール#23 – AWSコマンドを実行するルートユーザ
AWSアカウントのルートユーザを使ってAWSコマンドを実行してはいけません。おしまいですです。
AWSアカウントのルートユーザのアクセスキーは、課金情報を含む全てのAWSサービスのリソースへのフルアクセスを与えます!!!!
例えば、AWSアカウントのルートユーザーを使って新しいEKSクラスターを作成することはないと思いますが、万が一に備えてこれを用意しておきましょう。もし、攻撃者がルートユーザーのアクセスキーにアクセスしたら、壊滅的な被害を受ける可能性があります。
ルールは非常に柔軟で、ユーザーにとっても透明性があります。ルールが何をするのか、なぜ特定のイベントがアラートをトリガーするのかを正確に把握することができます。
このようなことが決して起こらないことを願っています
…本番アカウントで！
すでにSysdig Secureのルールをランタイム検知に使用している場合は、クラウド環境になったからといって別のルールポリシー言語を学ぶ必要はありません。
同じUIから、まったく同じ言語を使ってクラウドとコンテナのルールを作成することができます。
また、Insights Cloud Activityビューでは、ワークロード保護（青枠）とクラウドセキュリティ（オレンジ枠）をつなぐ、セキュリティイベントの完全なタイムラインを見ることができます。
Sysdigでクラウドを守る
このトピックについてさらに詳しく知りたい方は、脆弱なコンテナから攻撃者がラテラルムーブメントを行い、クラウドインフラストラクチャー全体を危険にさらす方法についての記事をご覧ください。
Sysdig Secure for cloudでは、攻撃者が侵入する前にクラウドの設定ミスに継続的にフラグを立てたり、流出した認証情報からの異常なログインなどの不審なアクティビティを検出することができます。これらはすべて単一のコンソールで実行されるため、クラウドのセキュリティ態勢を簡単に検証することができます。しかも、わずか数分で始めることができます。
Sysdig Free Tierで無料でクラウドのセキュリティ対策を始めましょう！