AWS Organizationsを悪用したセキュリティ攻撃とは

1. そもそもAWS Organizationsとは

1-1. AWS Organizationsとは

AWS Organizationsとは、一言でいうと「複数のAWSアカウントを一元管理するためのサービス」です。

例えば、複数の部署で1つのAWSアカウントを利用していると、各部署で作成した仮想サーバー（EC2インスタンス）が混在してしまい、誤って他部署のEC2インスタンスを停止してしまったりすることが起こりかねません。

かといって部署ごとに単一のAWSアカウントをそれぞれ作成すると、利用料金がそれぞれのアカウントで発生してしまうため取りまとめが大変になります。また、各アカウントの利用状況が見えづらくなり、運用管理の負担も増加してしまいます。

AWS Organizationsの機能を使用すると、複数のAWSアカウントを一元管理することができるようになるため、例えば部署ごとにAWSアカウントを分けたとしても利用料金はOrganizations全体でまとまって請求されるため手動で取りまとめる必要はありません。また、各アカウントの利用状況が確認でき、各アカウントに対して利用制限をかけることも可能になるので簡単に管理することができるようになります。

複数アカウントを使い分けて大規模な利用をする際にはぜひとも利用したい機能です。

1-2. AWS Organizationsを使った便利な機能

AWS Organizationsで複数アカウント管理を行う際の便利な機能はさまざまありますが、代表的なものとして、サービスコントロールポリシー（SCP）という機能があります。

これは、Organizations管理側から各アカウントに対して「これは実行してよい」「これは実行してはダメ」といったことを定義することができる仕組みです。

これにより、例えば「仮想サーバーを置くのは日本だけにする（他の国で仮想サーバーを起動してはダメ）」や、「AWSアカウントを担当者が誤って削除できないようにする」といった制限を行うことが可能です。

SCPの他にも、CloudTrailをOrganizations全体で使用することで各アカウントの操作ログを一か所に集約して保存することができたり、Guard DutyをOrganizations全体で使用することで不正なアクティビティを複数アカウントでまとめて検知・通知する仕組みを作成するといったことも可能です。

セキュリティ攻撃対策について、NTT東日本のセキュリティエンジニアがお応えします。お気軽にお問い合わせください。

2. 攻撃者の悪用方法と影響

2-1. 攻撃者の悪用方法

攻撃者は、自身が持つOrganizationsに標的のAWSアカウントを移動することにより、AWSアカウントを支配しようとします。

具体的には、攻撃者のOrganizationsから攻撃対象のAWSアカウントに対してOrganizationsの招待を送信し、攻撃対象のAWSアカウント上でそれを承認します。

承認には本来AWSアカウント側で承認操作が必要ですが、ユーザー認証情報（ID／パスワード）の漏えいなどにより攻撃者が認証情報を持っている場合、攻撃者側で承認操作を実行できてしまいます。

一度攻撃者のOrganizationsに入ってしまうと、前述したSCPを利用することで該当のAWSアカウントを制御することが可能になってしまいます。

2-2. 攻撃を受けた際の影響

SCPは「これは実行してはダメ」という制限を各AWSアカウントに対してかけることが可能ですので、あらかじめ攻撃者のOrganizationsにおいて「各AWSアカウントにおける全ての操作を禁止する」という制限をかけておくことで、OrganizationsにAWSアカウントが移動した瞬間から、元の持ち主は全ての操作ができなくなってしまいます。

そして、そのSCPに例えば「攻撃者からの操作は例外として全ての操作が可能」という例外条件を入れておくことにより、攻撃者だけがそのAWSアカウントを自由に利用するといったことが可能になります。

いわゆる、AWSアカウントのハイジャックです。

このようにAWSアカウントが攻撃者のOrganizationsに移動してしまうことにより、例えばCloudTrailによる操作ログ管理から外れることによってアカウント上でどのような操作が行われたかを追うことができなくなり、Guard Dutyによる不正なアクティビティ検知も行われなくなります。

セキュリティ攻撃対策について、NTT東日本のセキュリティエンジニアがお応えします。お気軽にお問い合わせください。

3. どのようにして攻撃からアカウントを守るか

3-1. SCPの設定

それでは、こうした攻撃からアカウントを守るにはどうすればよいのでしょうか。

まずは、既にOrganizationに参加しているAWSアカウントを利用中であれば、そのOrganizationにおいてサービスコントロールポリシー（SCP）を設定することで組織間の移動を禁止することが可能です。

実際にどのようなSCPを設定すればいいのかについては、以下のAWSブログにおいて紹介されています。

AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール | Amazon Web Services ブログ

3-2. ユーザー認証情報の管理

AWSで発生しているセキュリティインシデントの最も多い原因が「AWS認証情報の漏えい」であり、全体の約7割を占めるそうです。

AWSアカウントのユーザー認証情報が悪用され意図しない操作が行われないよう、AWSアカウントにおけるユーザー認証情報は正しく管理しておく必要があります。

具体的には、まず以下のユーザー・アクセスキーが存在しないか確認しましょう。

MFA未設定のルートユーザー

• MFA未設定のIAMユーザー
• 90日以上使われていないIAMユーザー
• 90日以上使われていないアクセスキー
• 90日以上ローテーションされていないアクセスキー

まず、長期間使用されていないIAMユーザーやアクセスキーなどの認証情報は不要であれば削除しましょう。

MFAとは多要素認証のことで、ログインする際にワンタイムパスワード等を追加で求める機能です。これにより、万が一ユーザー名とパスワードが漏えいした際のリスクを軽減することが可能になります。特にルートユーザーに対するMFAの設定は必ず行いましょう。

もし、「そもそもルートユーザーを使用する予定がない」という場合は、AWS Organizationsの機能を利用してルートユーザーの認証情報そのものを削除し、誰もルートユーザーを利用できないようにすることも手段の一つです。

ルートユーザーの認証情報を削除して利用できないようにする方法については以下のAWS公式ページにおいて紹介されています。

AWS アカウントのルートユーザー - AWS Identity and Access Management

こうしたユーザー認証情報の確認を定期的に行い、AWSアカウントにおけるユーザー認証情報が適切に管理されているか確認することが重要です。

セキュリティ攻撃対策について、NTT東日本のセキュリティエンジニアがお応えします。お気軽にお問い合わせください。

4. まとめ

AWSにはさまざまな便利な機能がありますが、それが悪用され攻撃に利用されるケースがあります。できる対策をしっかりととりながら、安全にAWSを利用しましょう。

なお、NTT東日本のAWS請求代行サービスをご利用中のお客さまについては、前述したSCPによる対策を実施しているとともに、定期的にAWSアカウントに対するユーザー認証情報の設定状況についてレポートを送付しています。

ご利用中のAWSアカウントにおいてMFAが設定されていないユーザーがいないか、長期間使われていないユーザーが存在しないか等の情報をお届けしているとともに、ご希望に応じてWebミーティングを通じた設定支援も行っております。セキュリティ強化にぜひお役立てください。

セキュリティ攻撃対策について、NTT東日本のセキュリティエンジニアがお応えします。お気軽にお問い合わせください。

Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。