Sysdig SecureによるAWS IAMの保護

本文の内容は、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用のすぐに使えるルールの完全なセットは以下の通りです。

#ルール説明プライオリティ1Add AWS User to Groupユーザーをグループに追加することを検出
INFO2Attach Administrator Policy管理者ポリシーのユーザーへのアタッチを検出
WARNING3Attach IAM Policy to UserIAM ポリシーのユーザーへのアタッチを検出
NOTICE4Create Group新しいユーザー グループの作成を検出
WARNING5Create Security Group Rule Allowing SSH IngressSSH penetrationを許可するセキュリティグループルールの作成を検出
ERROR6Create AWS user新しい AWS ユーザーの作成を検出
INFO7Create IAM Policy that Allows Allすべてを許可する IAM ポリシーの作成を検出
CRITICAL8Create Access Key for Root Userルートユーザーのアクセスキーの作成を検出
CRITICAL9Create Security Group Rule Allowing Ingress Open to the World すべてを許可するイングレスのセキュリティグループルールの作成を検出
CRITICAL10Console Login Failureコンソールログインの失敗を検出
WARNING11Console Login Without MFAMFAを使用しないコンソールログインを検出
CRITICAL12Console Root Login Without MFAMFAを使用しないルートコンソールログインを検出
CRITICAL13Deactivate Hardware MFA for Root Userルートユーザーのハードウェア MFA 設定の無効化を検出
CRITICAL14Deactivate MFA for Root UserルートのMFA設定の無効化を検出
CRITICAL15Deactivate Virtual MFA for Root Userルートの仮想MFA設定の停止を検出
CRITICAL16Delete Virtual MFA for Root Userルートの MFA 設定の削除を検出
CRITICAL17Deactivate MFA for User Accessユーザーアクセス用の MFA 設定の無効化を検出
WARNING18Logged in without Using MFAMFA (multi-factor authentication)を使用せずにユーザーがログインしたことを検出
CRITICAL19Delete Groupユーザーグループの削除を検出
WARNING20Password Recovery RequestedAWS IAM のパスワードリカバリー要求を検出
WARNING21Put IAM Inline Policy to UserIAM インラインポリシーのユーザーへの適用を検出
NOTICE22Put Inline Policy in Group to Allow Access to All Resources すべてのリソースへのアクセスを許可するグループにインラインポリシーを入れたことを検出
WARNING23Root User Executing AWS CommandルートユーザーがAWSコマンドを実行していることを検出
CRITICAL24Update Account Password Policy Not Requiring 14 Characters14文字以上の長さを必要としないパスワードポリシーの更新を検出
WARNING25Update Account Password Policy Not Requiring 7 Charactersパスワードポリシーを更新する際に、7文字以上の長さを必要としないことを検出
WARNING26Update Account Password Policy Expiring in More Than 90 Days90日以上経過したパスワードポリシーの更新を検出
NOTICE27Update Account Password Policy Not Expiring更新するパスワードポリシーの有効期限が設定されていないことを検出
NOTICE28Update Account Password Policy Not Preventing Reuse of Last 24 Passwordsパスワードポリシーを更新しても、過去24個のパスワードの再利用が防止されていないことを検出
NOTICE29Update Account Password Policy Not Preventing Reuse of Last 4 Passwords更新中のパスワードポリシーで、最後の4つのパスワードの再利用を防止していないことを検出
WARNING30Update Account Password Policy Not Requiring Lowercase小文字の使用を要求していないパスワードポリシーの更新を検出
WARNING31Update Account Password Policy Not Requiring Numberパスワードポリシーを更新した際に、数字の使用が要求されていないことを検出
WARNING32Update Account Password Policy Not Requiring Symbol記号の使用を必要としないパスワードポリシーの更新を検出
WARNING33Update Account Password Policy Not Requiring Uppercase大文字の使用を必要としないパスワードポリシーの更新を検出
WARNING34Update 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で無料でクラウドのセキュリティ対策を始めましょう！