Unit 42クラウド脅威レポート更新: IAMに設定ミスのある組織数の増加でクラウドのセキュリティ状況は悪化

This post is also available in: English (英語)

概要

Unit 42の新しい調査によると、クラウド環境は、昨年末よりも攻撃を受けやすくなっています。クラウドサービスプロバイダ（CSP）のインスタンスにおいて、多要素認証（MFA）を有効にしていなかったり、アクセスキーのローテーションを行っていなかったり、過度に寛容なサービスアカウントを使用している組織の数が大幅に増加していることを確認しました。このような組織は、CSP環境のアイデンティティおよびアクセス管理（IAM）アカウントの侵害による重大セキュリティインシデントを経験するリスクが高まります。

これらの調査結果は「Unit 42クラウド脅威レポート2020年2H」を補足するものです。2020年10月のレポートでは、IAMの設定ミスがクラウド環境にもたらすセキュリティリスクを分析しました。特に、SolarStormやMicrosoft Exchange Serverへの攻撃におけるMFAの極めて大きな影響を踏まえ、この8ヶ月間でトレンドがどのように変化したかを確認するためにこの調査を追跡することにしました。

Unit 42のリサーチャーは「クラウド環境は2020年10月より現在の方がより攻撃を受けやすくなている」ということを2021年1月から6月にかけての調査で確認しました。最も重要なのはリサーチャーが以下の追加の発見をしたことです。

• Google Cloudのストレージバケットをすべてのユーザがアクセスできるように設定している組織が60%増加し、データのリスクが高くなっている
• Amazon Web Services（AWS）プラットフォームのルートアカウントのMFA設定を有効にしていない組織が42％増加している
• アクセスキーが90日以上ローテーションされていないAWSを利用している組織の数が22%増加している

これらの結果（MFAの無効化、定期的なアクセスキーのローテーション運用の欠如、過剰な特権アカウントのプロビジョニング）は、組織がDevOpsのセキュリティ運用手順を強化する必要があることを示しています。

すべての組織が、なんらかのクラウドネイティブなセキュリティプラットフォームに投資し、本番環境と開発環境の両方でIAMの設定ミスがないかクラウド環境を定期的に監視することが強く推奨されます。パロアルトネットワークスではPrisma Cloudをクラウドネイティブなセキュリティプラットフォームとして提供しています。

MFAの設定ミス

この調査結果における「クラウド環境でMFAを有効にしていない組織」というのはCSPにネイティブなIAM機能に関連するもののみを含みます。サードパーティのIDプロバイダ（IdP）が提供するものは含まれません。CSP のルートアカウントは、企業のクラウド IAM セキュリティにおいて重要なセキュリティ上のボトルネックとなっています。CSPのルートアカウントはクラウド環境で最初に作成されるアカウントで、あらゆるIdPの設定の許可や管理を含め、いわば「王国への鍵」を握っている全能アカウントです。つまり「CSPのルートアカウントが侵害されればIdPの導入するセキュリティ対策も回避される」という点を指摘するのは重要でしょう。

組織のCSPルートアカウントにMFAを設定して、組織のクラウド環境自体も含めて保護することは、セキュリティのベストプラクティスです。たしかにMFA をバイパスできる場合もありますが（フィッシング攻撃、安全でないプロトコル、脆弱性など）、このようなタイプの攻撃は攻撃者にとっては非常にコストがかかるものです。Microsoftの調査によると「パスワード以外のものを使用すると攻撃者のコストが大幅に増加する。そのため、あらゆるタイプのMFAを使用したアカウントの侵害率は、集団全体の0.1％未満である。」とのことです。またIDCは「2022年までに90％の企業が生産要件を満たすためにクラウドインフラストラクチャに依存するようになる」としています。MFAのベストプラクティスに従ってクラウドインフラの安全を確保しておくことで、組織は本来避けられるはずのIDセキュリティ流出被害に遭いづらくなります。

MFAは二要素認証（2FA）とも呼ばれ、アプリケーションへのアクセスを許可する前に、2つ以上の形式の認証手段を提供するプロセスです。認証には次の3つの要素があります。

1. 知識（Something you know）
   • パスワード
   • パスフレーズ
2. 所有（Something you have）
   • ハードウェアセキュリティキー
   • ソフトウェアトークンアプリケーション
   • SMSトークン
3. 生体（Something you are）
   • バイオメトリックスキャンまたは虹彩スキャン
   • 音声認証

MFAが有効で、ユーザーがアプリケーションへのアクセスを要求した場合、アクセス許可の前にユーザーは2要素以上の認証チェックに成功することが求められます。これによく使われるのが「パスワード（知識要素）」の入力と「トークン値（所有要素）」の入力です。

前述の「Unit 42クラウド脅威レポート2020年2H」でUnit 42のリサーチャーは、MFAの設定ミスのうち「組織がルートアカウントと標準ユーザーアカウントのMFAリソースを適切に有効化ないし設定していないケース」について調査しました。残念ながら2020年10月以降、これらの統計は悪化しています（表1参照）。今回これが悪化傾向となった要因として考えられるのが、「組織がユーザーアカウントを適切に設定できておらず、IdPプラットフォームの範疇外に問題がある」ということです。つまり、組織がOkta、Auth0、SailPoint、OneLoginなどのIDプロバイダを利用している場合でも、クラウドプラットフォーム内で作成したIAMアカウントを無効にしていない可能性がある、ということです。これにはIdP統合の確立のために使用されたIAMアカウントも含まれます。

^{表1 IAM アカウントの MFA が無効になっている組織
*RAM - Resource Access Managementは、Alibaba Cloud内のIDとアクセス制御のサービス。これによってユーザーとその権限を一元管理できる}

Amazon Web Services（AWS）、Oracle Cloud、Alibaba Cloudでは、IAM認証機能をクラウドプラットフォーム自体に搭載しているのに対し、Google CloudやMicrosoft Azureでは、クラウドプラットフォームに自社のIdPサービスを利用してIAM認証を行っています。Google Cloudは自社サービスの「Google Accounts」を、AzureはMicrosoftのサービス「Azure Active Directory（AD）」を使用します。組織管理者がGoogle CloudアカウントのMFAを有効にする場合は、こちらのGoogle Workspaceガイドを参照してください。組織管理者がAzureクラウドのアカウントでMFAを有効にしたい場合は、こちらのAzure AD Multi-Factor Authenticationガイドを参照してください。

この他の設定ミス

それでは次に、IAMアクセスキーのローテーション運用について見ていきましょう。こちらの調査結果では、2020年10月から2021年6月にかけて、アクセスキーのローテーションを実施していないクラウド利用企業は、世界的に約20％増加していたことがわかりました。この傾向はGoogle Cloud、AWSのプラットフォームを使用している組織で見られたものです。

パスワードと同様に、新しいCSPアクセスキーは90日ごとにローテーションし、キーが漏れたり盗まれたりしても長期間有効にならないようにする必要があります。アクセスキーがGitLabやGitHubなどのコードリポジトリサイトに誤ってアップロードされたり、アクセスキーを置いてあるクラウドインスタンスがその後侵害されることで、漏えいすることがあります。表2に示したとおり、AWS、Google Cloud、Oracle Cloudのプラットフォームを使用している組織では、長期間に渡ってアクティブなアクセスキーが顕著に見られました（各クラウド事業者はこの種の問題からクラウド基盤を保護するための設定をユーザーが行えるようにしていますが、これを有効にしていないユーザーが見られる）。

クラウド需要の増加とその複雑化に加え、全体として認証の長期利用を深刻に受け止めない傾向が見られます。このことから、組織はアクセスキーの設定ミス問題に対処するよりも、オンプレミスからクラウドへの移行やアプリケーション開発など、他のクラウド開発関連作業に対処することを優先してしまっているのではないかと考えられます。ですが、アクセスキーのローテーションは、単調増加するリスクの深刻度を下げる数少ない実用例の一つです。認証情報が変更されなかった期間が長ければ長いほど、その認証情報を使用するクラウドインフラが構築されればされるほど、その認証情報が漏えいした場合の組織への影響は大きくなります。

^{表2 アクセスキーのローテーション運用を行っていない組織}

主要なCSPはそれぞれ、アクセスキーのローテーションプロセスを自動化する方法を提供しています。詳しくはそれぞれのリンクをご覧ください（Alibaba Cloud、AWS、Azure、Google Cloud、Oracle Cloud）。

権限過剰

最後に、Unit 42のリサーチャーは、IAMアカウントとロールについて、権限を過剰に設定している組織がどの程度あるかを再調査しました。最も目立ったIAM権限過剰問題は、AWS AssumeRole機能を中心とした乱用です（AWSはAssumeRoleの乱用を防ぐ設定を用意していますが、これを有効にしていないユーザーもいます）。このサービスは、Unit 42のリサーチャーからもCSO Online業界のベストプラクティス記事からも注目を集めていますし、SolarWindsもこのAssumeRoleサービスの設定ミスと関連があります。このような注目度の高さからAssumeRoleに過剰な権限を付与する組織数は減少し始めており、わずか6ヶ月の間に67％も減少していることをリサーチャーは確認しています（表3参照）。

^{表3 過度に寛容なIAM特権を認めている組織}

過度に寛容な権限を認めるAWSのAssumeRoleサービスが減少したことは良いニュースですが、そろそろ他のCSP環境に存在するこれとは別のIAMセキュリティ問題の解決にむけ、全員が意識を切り替えるほうがよさそうです。たとえばGoogle Cloud環境内でIAMサービスアカウントに権限が過剰に設定されているケースは17%も増加していますし、誰でもアクセス可能なGoogle Cloudストレージリソースは過去6カ月間で60%も増加していますので、これもアクセスを適切に制限する必要があるでしょう。

結論

CSPのルートアカウントは、クラウド環境に重大なセキュリティリスクをもたらします。これらのアカウントに適切なセキュリティ保護を提供することは、クラウドを利用している企業にとっては喫緊の課題です。クラウド環境の設定や保守が不適切だと深刻な事態を招きかねません。Unit 42のリサーチャーは、組織からCSPルートアカウントを使って行うオペレーション機能は、IdPプラットフォーム設定のみに制限することを強く推奨しています。CSPのルートアカウントは、できればMFAハードトークンでMFAを有効化し、緊急時を除いてそのルートアカウントを決して使用しないようにします。すべての管理機能は、IdPベースで新たに指定された管理アカウントで実行する必要があります。

また、IAMアクセスキーをローテーションしていない組織数や、権限過剰のIAMアカウントやロールを導入している組織数が増加していることも判明しました。ユーザーパスワードのローテーションと同様に、リスクを最小限に抑えるには少なくとも90日ごとにアクセスキーをローテーションする必要があります。最後に、ユーザー、ロール、グループ特権など、すべてのIAMエンティティの作成・管理にあたっては最小特権の原則を適用する必要があります。なお、本稿で取り上げた重要なIAM設定ミスはPrisma Cloudではとくに追加設定もなしで検出・警告可能です。Prisma Cloudプラットフォームを使うととくにマルチクラウド利用組織ではクラウド環境構成の把握が容易になります。

推奨される対策

• CSPのルートアカウントはできるかぎりMFAハードトークンでMFAを有効化する
• CSPのルートアカウントはIdP設定のセットアップのみに利用し同じアカウントを他の機能には使用しない
• IdP経由で作成・設定したIAM管理アカウントを使ってすべての管理機能を実行する
• Prisma Cloud IAMモジュール経由でIAMロール、グループ、トラストポリシーを監視する
• すべてのIAMユーザー、サービスアカウントに対し、アクセスキーのローテーション機能を自動化して運用する
• IAMの権限設定には最小特権の原則を用いる

追加資料

• 『Unit 42クラウド脅威レポート』2020年秋版の注目ポイント
• Unit 42クラウド脅威レポート: 設定が不適切なIAMロールが何千ものクラウドワークロードの侵害を招く