2020年版 クラウドセキュリティの現状

主な調査結果

• 63%がクラウドアクセスに多要素認証を利用していない
• 50%がアクセスキーのローテーションを定期的に実施していない
• 92%がクラウドストレージへのアクセスをログに記録していないため、インシデントのフォレンジック分析を実行できない
• 26%のワークロードでSSHポートがインターネットに公開され、20%のワークロードでRDPが公開されてしまっている

 

パブリッククラウドによって、あらゆる規模の企業が、これまでにないスケーラビリティ、パフォーマンス、俊敏性を手に入れられるようになりました。開発チームが新製品やアプリケーションをこれまで以上に迅速に本番運用へと移行できるようになり、組織におけるデジタルトランスフォーメーションが加速しています。しかしながら、クラウドの採用が一足飛びに進むわけではありません。クラウドベンダが膨大なセキュリティリソースを自社のプラットフォームに投入しているにもかかわらず、クラウドのセキュリティインシデントが報道されない日はほとんどありません。これらのインシデントを突き詰めれば、その多くは、サービスそのもののセキュリティの不備ではなく、クラウドサービスの安全性を欠いた利用によって発生しています。

Zscaler ThreatLabZチームはパブリッククラウドのセキュリティの現状を知るため、AWS、Azure、Google Cloud Platform（GCP）で大量のワークロードを処理しているお客様の環境から、匿名化された統計情報を収集しました。また、Microsoft 365（M365）を利用されているお客様から、ユーザやアプリケーションの設定をサンプリングしました。

この記事では、その調査結果の概要を紹介し、今後の記事で、ThreatLabZチームが確認したクラウドベースの攻撃、特定のタイプのクラウドの構成ミスのリスク、セキュリティインシデントから保護するための対策を詳しく解説する予定です。

 

クラウドセキュリティ責任共有モデル

クラウドのセキュリティとコンプライアンスでは、CSP（クラウドサービスプロバイダ）と顧客が責任を共有します。これは、すべてのCSPが告知している、クラウドサービスそのもののセキュリティはCSPが提供するものの、クラウドサービス内のセキュリティは顧客の責任であるとするモデルです。

利用するクラウドサービスのタイプによって、責任の分担方法が異なります。M365やSalesforceなどのSaaSアプリケーションでは、物理的なセキュリティからオペレーティングシステム、アプリケーションそのものまでのアプリケーションのセキュリティ全体の管理の責任をクラウドベンダが負います。

IaaSプラットフォームの導入環境の場合は、セキュリティやサービスの構成などのかなりの部分の責任を顧客が負うことになります。多くの場合、アプリケーションコードやオペレーティングシステムもこれに含まれます。

企業のデータセンタあるいはパブリッククラウド環境のどちらにあるとしても、データが適切に保護されるようにすることは、いかなる場合も企業側の責任です。

 

クラウドセキュリティプラットフォームに関する調査結果

調査データのレビューによって、広く報じられているセキュリティ問題における対策は、ほとんどの環境で不十分であることがわかりました。問題が存在する主な領域は以下の通りです。

 

• ログや監視の欠如
  侵害などのセキュリティインシデントが発生した場合に最初にそのイベントの情報を検索するのが、ログファイルです。セキュリティ関連の問題が発生していない状況においても、ログが確実に収集されていれば、クラウド環境での出来事を十分に理解できます。AWS CloudTrailやAzure MonitorなどのCSPツールを利用することで、必要な場合にこれらの情報を確実に入手できます。ただし、有効にしておかなければ機能しません。我々の分析によると、20%近くの実装でCloudTrailが有効になっておらず、また、半数以上はログの継続保存日数をデフォルトの90日間以上に設定していないことがわかりました。


• 過度の権限
  情報流出の大半に不正取得した認証情報が悪用されていることを考えれば、クラウドのアクセスキーや認証情報がサイバー犯罪者に真っ先に狙われるのは当然のことです。セキュリティの強度に関係なく、正しい認証情報が手元にある攻撃者であれば、正面玄関から中に入ることができます。代表的な例として、攻撃者がGitHubのレポジトリからハードコーディングされたAWSの認証情報を入手して5,700万人のユーザの個人情報（PII）が流出したUberの例、フィッシング被害によってAWSから会社のすべての資産が消去されてしまったCode Spacesの例などが挙げられます。我々の分析では、多要素認証を使用せず、ハードコーディングされ、ローテーション期間が長すぎるアクセスキーを使用している組織の割合が多いことがわかりました。


• ストレージと暗号化
  クラウドストレージバケットが外部に公開されてしまっていたために発生した大規模情報漏洩が数年前から数多く報道されています。ロサンゼルス・タイムズ、テスラ、米国共和党、ベライゾン、ダウ・ジョーンズなどは、この間違いを犯してしまった有名な組織のほんの一部です。大々的な報道にもかかわらず、クラウドストレージが今もクラウドの構成ミスが最も多い分野であることに変わりありません。不十分なアクセスポリシー、暗号化の欠如、ポリシー適用の不徹底、暗号化されていないプロトコル経由のアクセスは、最も一般的な問題のほんの一部に過ぎません。


• ネットワークセキュリティグループ
  ネットワークセキュリティグループは、クラウド環境におけるすべてのサービスのネットワーク接続をコントロールし、ネットワークファイアウォールと同様の役割を果たします。ところが残念なことに、このグループは、クラウドストレージに次いで2番目に多くの構成ミスが発生する領域になっています。人為的ミスの結果としてこのような構成ミスが発生することもありますが、それ以外に、接続を容易にしたり複雑さを回避したりする目的でセキュリティグループが意図的にオープンのままになっていることもあります。SSH（Secure Shell）やRDP（Remote Desktop Protocol）などの外部に公開されているプロトコルは誰もが知るところであり、攻撃者はこれを悪用することで、感染システムを乗っ取る、あるいは組織のクラウド環境内でラテラルに移動することが達成できてしまいます。

 

ログや監視の欠如

多くのクラウド環境では、数GB（ギガバイト）級のデータが常に送受信されています。クラウド環境での出来事を十分に理解するには、堅牢なログと監視のシステムが必要です。

たとえばAWS CloudTrailは、AWS環境のAPIコール、アクション、変更に関する情報を収集するログサービスです。CloudTrailログには、監査や不正侵入へのレスポンスに役立つ重要な情報が含まれています。CloudTrailはデフォルトで有効になり、すべてのアクティビティとイベントが90日間記録されますが、90日以上にする必要がある場合は、CloudTrailを構成して、ログに記録されたイベントがAmazon S3バケットに配信されるようにする必要があります。

AWS CloudWatchは、メトリクスを収集、追跡し、ログファイルの監視し、環境内の一般的なイベントへの自動応答を展開します。

 

影響

実際に攻撃された場合、最初の情報源としてログが利用されることが多く、インシデントにおいてログは重要な役割を果たします。

 

対策

• CloudTrail/Azure Monitorが有効であることを確認します。
• ログがS3バケット/Azure Storageに長期にわたって保存されるようにし、ライフサイクル管理を構成します。
• （少なくとも）S3サーバ側暗号化を有効にします。

 

統計情報

• 92%のS3バケットでアクセスログが有効になっていませんでした。
• 99%でサーバ側と移動中の暗号化が必須になっていませんでした。
• 18%でCloudTrailが無効になっていました。
• 58%でCloudTrailログがS3に長期保存されるようになっていませんでした。
• 78%のS3バケットでライフサイクルが構成されていませんでした。
• 100%のEC2インスタンスで詳細監視が有効になっていませんでした。
• Azure Monitorアラートが構成されているアカウントはありませんでした。
• AzureのSQLデータベースまたはVMの89%で詳細診断が有効になっていませんでした。

 

 

過度の権限

影響

アクセスキーや認証情報は多くの場合に、サイバー犯罪者の最初の標的です。これらを手に入れれば、セキュリティポリシーやファイアウォールルールに関係なく、攻撃者がクラウドアカウント全体にアクセスできます。

 

例

• 2014年のCode Spacesに対するフィッシング攻撃では、同社のコンソール認証情報が流出しました。この攻撃者によって、AWSに置かれていた同社の資産のほとんどが消去されてしまいました。¹


• 2016年にGitHubレポジトリのハードコーディングされたAWS認証情報を攻撃者が手に入れ、Uberの5,700万人のユーザのPIIが流出しました。²


• マリンド・エアの元従業員が自らのアクセス権を悪用し、3,500万人分の顧客レコードを流出させました。³

 

対策

MFA（多要素認証）

• コンピューティングシステムへの認証方法としてはパスワードが最近の主流です。使用するシステムごとに一意で推測が困難なパスワードを選択することが重要ですが、数百のサイトを利用しているユーザがそのような条件でパスワードを生成し、記憶するのは不可能です。そこで、第2の認証要素の利用がますます重要になっています。


• お客様の環境の分析で、大多数のお客様が、ハードウェアあるいはソフトウェアベースのMFAを利用していないことがわかりました。

 

キーのローテーション

• アクセスキーは、ユーザ名とパスワードと同じですが、プログラミングで使用されます。


• ユーザがこれらをパスワードと同じように注意して取り扱うことはなく、コードにハードコーディングされて平文で保存されます。


• キーが外部に公開されてしまうのを制限するには、定期的なローテーションが必要です。


• 使用していないキーを無効にする必要もあります。

 

最小限の権限の原則

• 「root」ユーザを使用せず、必要とする特定の権限だけを許可してユーザを作成します。


• ポリシーをユーザではなくグループに割り当てることで、一貫性が保証されるようにします。


• 有効期間が長いアクセスキーの代わりに、ロール（IAMロール、Azure RBAC）を使用します。

 

統計情報

 

• 50%の環境で、アクセスキーが定期的にローテーションされておらず、使用可能なキーが長期にわたって読み取り可能な状態になっていました。


• 63%のAWSコンソールIAMユーザがMFAを利用していませんでした。


• AWSアカウントで、28％のアクセスにロールやグループではなくキーが使用されていました（ロールであれば、アクセスの一貫性と最小権限の原則が保証されます）。


• 84%が、IAMポリシーをグループではなくユーザに割り当てていました。


• 14％のIAMユーザが非アクティブでした。

 

ストレージと暗号化

対象

最も一般的な構成ミスは、クラウドストレージバケットとその内部のオブジェクトに関連するもので、これが、機密情報にとって大きなリスクになり、データ侵害の最大の標的になっています。具体例としては、ストレージバケットとそのコンテンツを初期化して本番運用を開始する際に多く確認される、次のような構成ミスがあります。

 

• ストレージバケットのアクセスポリシーが不十分である
• アクセスポリシーがすべてのユーザに漏れなく適用されていない
• ストレージバケットのコンテンツが暗号化されていない
• 非セキュアチャネル経由でストレージバケットからコンテンツにアクセスしている
• バックアップストレージとそこに置かれているオブジェクトが暗号化されていない

 

影響

これらの構成ミスによって、承認されていないユーザがストレージバケットにアクセスできてしまう可能性があります。

• 企業秘密や何らかの理由で非公開にすべき機密データをダウンロードし、公開する
• マルウェア/ランサムウェアが含まれる不正プログラム/ファイルをアップロードする
• 既存のコンテンツを書き換える
• バックアップストレージバケットを破壊する

 

例

• 2018年にロサンゼルス・タイムズで、構成ミスによってストレージバケットがインターネットに公開され、最終的に大規模クリプトジャッキング攻撃に発展しました。


• 同時期にテスラでもクラウドアカウントがハッカーに不正取得され、暗号解読などの目的で悪用されました。ハッカーがテスラのクラウドアカウントに侵入できたのは、アカウントがパスワードで保護されていなかったためです。


• 今年の初めにクラウド通信PaaS（Platform-as-a-Service）を提供するTwilioによって報告されたインシデントでは、S3バケットの構成ミスによってサイバー犯罪者がTaskRouter JavaScript SDKを不正取得し、書き換えたことがわかりました。

 

対策

厳格なアクセスポリシーをすべてのユーザに漏れなく適用する

• ストレージバケットとそこに含まれるコンテンツに適用するアクセスポリシーについては、すべてのユーザに対して、厳格かつ漏れなく適用する必要があります。そうすることで、クラウドストレージのインスタンスがインターネットに公開されてしまう可能性を、完全に排除できないまでも、最小限にできます。


• アクセスポリシーをユーザに関連付けるのではなく、ロールベースのアクセスポリシーを採用することで、アクセスポリシーを漏れなくユーザに適用できます。

 

ストレージバケットのコンテンツを暗号化する

• ストレージバケットのコンテンツを最も強力な暗号方式で暗号化することで、データ漏洩に備え、攻撃者による実コンテンツの解読を困難にできます。これにより、インシデント発生時の被害を最小限にできます。

 

暗号化されたチャネル経由でストレージバケットからコンテンツにアクセスする

• SSL/TLSプロトコルを有効にすることで、通常のHTTPプロトコルではなく、セキュアチャネル経由でストレージバケットやストレージのコンテンツにアクセスします。

 

バックアップのストレージバケットとそのコンテンツを保護する

• バックアップストレージとそこに置かれているバックアップデータに対し、厳格なアクセスポリシーと暗号化が漏れなく適用されるようにすることが重要です。

 

アクセスポリシーや自動化を頻繁に監査する

• 厳格な監査プロセスを整備し、ストレージバケット構成の設定やアクセスポリシーの監査を頻繁に実施することをお勧めします。


• 最適なセキュリティプラクティスをすべてのユーザに漏れなく適用し、構成ミスを迅速に検知するには、高度な自動化が不可欠です。

 

堅牢なアラート

• 堅牢なアラートのメカニズムを採用して、クラウドの管理者やユーザに構成ミスを迅速に通知することが非常に重要です。

 

統計情報

CSPM組織が収集した内部統計情報から、以下のことがわかりました。

• 約78％のユーザアカウントで「パブリックアクセスをブロックする」オプションが無効になっていましたが、これでは、そのユーザが所有するストレージバケットがインターネットに公開されるリスクが高くなります。


• 約80%のアカウントがディスク暗号化を有効にしておらず、約24%のアカウントが暗号化されたEBS（Elastic Block Storage）を使用していませんでした。


• 驚くべきことに、91％のストレージアカウントが、非セキュア通信チャネルを使用してデータにアクセスしていました。これらの非セキュア通信チャネルのほとんどは、他のモジュールがこれらのバケットのコンテンツへのアクセスを試行した場合に見つかったものですが、ほとんどのアカウントで、インターネットからのコンテンツアクセスに対してSSL/TLSオプションが有効になっていました。


• 一部のアカウントは、インターネットからリモートでオブジェクトにアクセスする場合も、HTTPSではなく、HTTPを使用していましたが、これでは、攻撃者が難なくストレージバケットにアクセスし、不正行為を実行できてしまいます。

 

 

• ほとんどのAzureアカウントで、ストレージバケットが暗号化されていました。おそらくこれは、Azureではデフォルトでストレージバケットに暗号化が適用されるようになっているためです。このような小さな対策を積み重ねることで、セキュリティポリシーがすべてのユーザに漏れなく適用されるようになります。


• 約85%のAzureアカウントで、デフォルトのネットワークアクセスルールが「拒否」に設定されていませんでした。これでは、インターネットやサイバー犯罪者にネットワークが公開されてしまう恐れがあります。

 

ネットワークセキュリティグループ

ネットワークセキュリティグループは、クラウドワークロードをインターネットから保護するネットワークファイアウォールのようなものです。ネットワークセキュリティグループは、適用するルールに基づいて、クラウドベースのサーバ/システムに出入りするトラフィックをコントロールします。

ネットワークセキュリティグループは、ストレージバケットの次に多く構成ミスが見つかる場所です。

これらの構成ミスは、意図しないヒューマンエラーにつながる可能性があります。IT管理者やユーザが、デバッグやリモートでの正規のネットワーク処理を許可するなどの目的でネットワークセキュリティグループのルールを緩めることがありますが、作業の終了後に元の厳しいルールに戻すのを忘れたために、ハッカーのクラウドベースシステムへの侵入を許してしまうことがあります。

クラウドユーザはデフォルトポリシーをそのまま適用する傾向がありますが、そのセキュリティは必ずしも十分ではありません。

 

影響

• クラウドベースのシステムを保護するルールが正しく構成されていないと、サイバー犯罪者がネットワークに侵入し、偵察攻撃を実行することで、インターネットに公開されているサーバやそこで動作するサービスを特定できてしまいます。


• 攻撃者は、偵察を試行するだけでなく、クラウドベースのサーバに大量のICMPパケットを継続的に送信することで（ICMPフラッドやpingフラッドと呼ばれます）、大量のサーバリソースを消費したり、インターネットのパイプを詰まらせたりすることで、DoS（サービス拒否）攻撃やDDoS（分散型サービス拒否）攻撃を実行することもできます。


• ネットワークセキュリティグループの構成ミスによって、攻撃者が外部に公開されているサービスやポートを悪用し、総当り攻撃や既知の脆弱性のエクスプロイトによってクラウドベースのシステムに不正侵入できてしまう恐れがあります。攻撃者は、複数の同時接続を開くことでDoS攻撃を仕掛け、システムをダウンさせることもできます。


• 不正侵入したサイバー犯罪者は、機密データを盗んだり公開したりする、マルウェアやランサムウェアを送り込む、他のシステムに水平移動するなどのあらゆる不正活動を実行できます。

 

例

• 昨年、「FritzsFrog」という名前の高度なP2Pボットネットが数か月にわたってSSHサービスを攻撃し、数百台のサーバを感染させていたことがわかりました。


• 今年の初めにソフォスによって確認されたクラウドスヌーパー攻撃は、すべてのセキュリティ対策を突破していたことがわかりました。ソフォスの調査結果によると、攻撃者は総当り方式で、インターネットに開かれているSSHサービスを経由して侵入したと推測されます。


• また、今年になって確認された、IoTやサーバを標的にする中国の新しいLinuxマルウェア「Kaiji」も同様のSSH総当り方式で侵入し、自らを拡散させるとされています。

 

対策

ゼットスケーラーはお客様に対し、ZTNA（ゼロトラストネットワークアクセス）アーキテクチャを実装して、すべてのアプリケーションを保護し、許可したユーザだけがアプリケーションにアクセスできるようにすることを強くお勧めします。Zscaler Private Accessなどのソリューションを正しく利用して、すべてのインバウンド通信をブロックし、感染システムからの水平移動を防止することで、外部からの攻撃を完全に排除できます。ZTNAの実装が進行中の場合は、以下のベストプラクティスを参考にしてネットワークセキュリティグループ/ポリシールールを作成し、クラウドリソースに適用することで、攻撃の標的になるリスクを最小限にできます。

 

特定のサービスやデータベースサーバへのインターネットからのインバウンドトラフィックをブロックする

• インターネットからTCPポート22へのインバウンドセッションやインターネットからTCPポート3389へのインバウンドセッションをブロックすることで、SSHやRDPなどのサービスに到着するトラフィックをブロックすることが極めて重要です。データベースサービスがインターネットに公開されると大きなリスクとなる恐れがあるため、インターネットからデータベースサービスに到着するトラフィックをブロックする必要があります。


• これらのサービスが他の非標準ポートで動作している場合は、それらのポートを明示的にブロックします。サービスが非標準ポートで動作していれば攻撃者に見つからないと考えるのは誤りです。たとえ非標準ポートで動作していたとしても、ハッカーがこれらのサービスを見つけるのはそれほど難しいことではありません。


• これらのサービスを正規のネットワーク処理やリモートのデバッグの目的で開放する必要がある場合も、指定したIPアドレスだけに制限する必要があり、インターネットのどこからでもアクセスできるようにしないことが重要です。

 

アウトバウンドトラフィックを制限する

• アウトバウンドフィルタ/ルールを無視せず、できるだけ厳しく設定します。アウトバウンドのサーバトラフィックを、正規の処理のためにサービスにアクセスする必要があるポートとIPアドレスだけに制限することを強く推奨します。このような制限は、システムが攻撃された場合に水平移動によって感染やデータの持ち出しが拡大するリスクを軽減し、被害を最小限にするのに役立ちます。

 

偵察の試行をブロックする

• ICMP pingは、ネットワーク接続をテストする非常に便利なツールであることから、システムの検出によく使われます。サイバー犯罪者によるサーバの特定を困難にするため、インバウンドとアウトバウンドのICMPトラフィックをブロックします。


• ポートスキャンやIPスキャンの試行をブロックします。スキャンは、攻撃者が標的にするシステムやサービスを特定しようとする目的で、ほとんどが攻撃の初期段階で実行されます。

 

ネットワークセグメンテーション

• セキュリティを考慮して設計したネットワークセグメンテーションは、データ侵害の限定と被害の軽減において非常に重要な役割を果たすため、極めて重要です。


• ネットワークの検知とレスポンスを導入することで、リアルタイムでトラフィックを監視し、脅威をすばやく特定して軽減できるようにします。

 

セキュリティパッチを迅速に適用し、常に最新バージョンを実行する

• クラウドベースのシステムで動作するアプリケーションやサービスに、公開されている最新のセキュリティパッチを必ず適用するようにします。


• 古いバージョンのソフトウェアが動作していると、システムがエクスプロイトに対して脆弱になり、最終的に重大なインシデントへと発展する恐れがあります。

 

統計情報

• インターネットに完全に公開されてしまっていたリソースの割合は5％と低いものでしたが、それでもまだ高すぎる数字です。これらの構成ミスを悪用すれば、攻撃者による組織のクラウド環境へのあらゆるアクセスが可能になります。

 

 

• 我々の調査で、26%のサーバで今もSSHポートがインターネットに公開されており、約20%のサーバでRDPが公開されていることがわかりました。これらの数字は依然として非常に高く、このような状態では、クラウドベースのリソースのリスクが高くなります。

 

結論

パブリッククラウドの利用の拡大に伴い、それを標的とする攻撃も増加しています。ただしこれは、パブリッククラウドはリスクが高く、利用しない方がいいという意味ではありません。ThreatLabZの調査で、パブリッククラウドインスタンスに対するサイバー攻撃のほとんどが、これらのインフラストラクチャの脆弱性ではなく、セキュリティの構成ミスから可能になっていることがわかりました。いくつかの簡単な手順を踏むことで、構成の安全性とデータの保護が保証されます。

---

¹https://www.infoworld.com/article/2608076/murder-in-the-amazon-cloud.html

²https://www.trendmicro.com/vinfo/pl/security/news/cybercrime-and-digital-threats/uber-breach-exposes-the-data-of-57-million-drivers-and-users

³https://www.zdnet.com/article/malindo-air-identifies-employees-of-e-commerce-contractor-behind-data-breach/