ラスベガスで今週、44,000 人もの参加者を集めた Amazon の今年最大のカンファレンス、AWS re:Invent が開催されました。私は、500 人近くにご参加いただいた月曜日のセッションにプレゼンターとして参加し、クラウドにおける主なセキュリティの脅威についてお話しました。また、共同プレゼンターである Sixt 社の Boyan Dimitrov 氏は、コンプライアンスとセキュリティの自動化について解説しました。そこで今日は、このセッションの内容を簡単にご紹介したいと思います。詳しい内容はビデオをご覧いただき、各トピックについては詳細記事とブログを参照してください。

S3 バケットの構成の不備

多くの攻撃者が多くの企業から S3 バケットのデータを盗み出すことに成功しています。S3 バケットのセキュリティを正しく構成するようにしてください。クラウドサービスの利用にあたっては、それぞれのサービスのベストプラクティスとセキュリティ制御を理解しておく必要があります。

鍵や認証情報の保護の欠如

最近のこのタイプのデータ流出としては、開発者がGithub にパブリッシュした鍵が 64,000 ドル超相当の許可されていないリソースのインスタンス化に使われた例があります。また、別の会社では、API を 1 つだけ作成していくつもの認証情報をそれで処理するようにしていたため、それを使えば全顧客データにアクセスできてしまっていたという例もあります。

エンジニアの権限が広い

エンジニアであれば、AWS アカウントのすべての処理を実行する権限があれば便利だと考えるものですが、エンジニアのラップトップがマルウェアに感染してしまうと、そのマシンに保存されている認証情報を使って実行できるあらゆる操作をマルウェアが実行できるようになります。したがって、必要なアクセスだけに制限し、役割を分担することで、リスクができるだけ少なくなるようにする必要があります。

ソフトウェアにパッチが適用されていない

WannaCry や Equifax などのデータ流出は、システムにパッチを適用して既知の脆弱性が存在するソフトウェアを実行しないようにしてさえいれば防ぐことができました。パッチの適用には難題もありますが、ビデオでは、パッチ管理のいくつかの推奨事項をご紹介しています。

不正ソフトウェアアップデート

適切なセキュリティプラクティスを順守している提供元やビジネスパートナーが提供するソフトウェアだけを使用するようにしてください。ウクライナのある企業がマルウェアを含むソフトウェアアップデートを誤って顧客に配布したことで、NotPetya が拡散しました。一般公開されているリポジトリで悪意あるバージョンのソフトウェアライブラリがホスティングされている場合もあります。

ネットワークポートのオープンの問題

パッチが適用していなかったことが WannaCry 拡散の原因ではありましたが、この攻撃でインターネット上の攻撃者がホストにアクセスして感染させるには、ポート 445 が開いている必要がありました。インターネットトラフィックを受信する必要のないポートをブロックしておかないのは、災いの窓を開けておくようなものです。最近では、AWS でネットワークにこのような対策をしていなかったホストが、ランサムウェアだけでなく、おそらくはビットコインマイニングにも感染していた例が報告されています。これについては、近日中にブログ記事で説明する予定です。

フラットなネットワーク設計

ネットワークを設計する際は、データベースをインターネットに直接接続しないでください。ネットワーク分離を使ってレイヤーを作成し、そこを通過しなければ攻撃者が最も価値の高いアセットに到達できないようにしておきます。そして、すべてのネットワークレイヤーで無効なアクセス試行を監視するようにします。可能であれば、WatchGuard Firebox Cloud、AWS WAF、Shield などのセキュリティサービスやカスタム作成の Lambda 関数を使用し、インターネットと保護対象アセットの間の API 要求を検証するようにします。

アプリケーションに対する権限が広い

インスタンス上のマルウェアは、そのホストで許可されている認証情報のどのような処理でも実行できます。開発者のアクセス権限と同様、システムのアクセス権限も必要最小限に制限しておきます。IAM のベストプラクティスに従い、EC2 インスタンスで IAM ロールを使用するようにしてください。

許可されていないリソース

インスタンスの権限が広いと、One Login のデータ流出で攻撃者がそうだったように、インスタンス上のマルウェアが許可されていないリソースをインスタンス化できてしまいます。

アセットの削除

さらに大きな問題なのは、他のリソースを削除する権限を持つインスタンスの攻撃者にアカウントのすべてのアセットを削除されてしまう可能性があることで、Code Spacesはその一番有名な例です。権限を制限し、常にバックアップを取っておくことが重要です。

データの不正取得

S3 バケットの情報漏えいは、アカウントからのデータ流出の最もわかりやすい例です。攻撃者がさらに手の込んだ方法を使って、ping パケットに余分なデータを埋め込んだり、DNS 要求と応答を不正に利用したりし、データをネットワークから持ち出す可能性もあります。WatchGuard Dimension などのツールでトラフィックを監視し、WatchGuard Data Loss Prevention などのセキュリティサービスを利用することをお勧めします。

「ブラック・スワン」

リスクモデルは、既知の脅威、未知の脅威、またはゼロデイマルウェアに使用できるものですが、異なる考え方が必要とされます。「ブラック・スワン」とゼロデイマルウェアの関連性に関する以前のブログ記事でその概念を説明しましたが、この「ブラック・スワン」を守るには、攻撃者だったらシステムをどういった方法で攻撃するかを想像し、どうすればそのような攻撃を回避できるかを考える必要があります。ゼロデイマルウェアについては、単純なパターンマッチングだけに頼ることなくマルウェアを検知できるツールの利用をお勧めします。

企業においては、構成管理を使用することで、ご紹介したようなクラウドにおけるセキュリティの脅威から自らを保護する必要があります。これらの脅威、コンプライアンス、セキュリティの自動化の詳細については、このセッションのビデオをご覧ください。

クラウドにおける主なセキュリティの脅威：AWS re:Invent