人依存ではクラウドの設定ミスの排除は不可能。CSPMによるAWSの自動修正を触ってみた。
こんにちは、大元です。さて、今日はクラウドセキュリテイの中でもニーズの高い、CSPM（ Cloud Security Posture Management )と呼ばれる技術について触れてみたいと思います。2017年頃からAWSを舞台とした設定ミスによる情報漏えいが多発するようになりました。S3バケットの公開権限が間違って設定されており、世界中の誰もがアクセス可能な状態で放置されているS3が多数発見されたというものです。
AWS社も改善は続けており、デフォルトの設定を変更したり、警告を出すようにしていますが、それでもなお設定ミスによる意図せぬ情報漏えいは後を絶ちません。
こういった「設定ミスを検出する」という目的で提供されるようになったのが、CSPMと呼ばれるセキュリテイソリューションです。
■自動修復機能を提供するようになったCSPM
CSPMの登場当時はセキュリティ監査テンプレートに基づいて設定ミスを検出するというのが主な目的でしたが、最近のCSPMには自動修復機能を持つもつものも登場してきています。マカフィーの提供するMvision Cloud for CSPMは自動修復機能を備えるCSPMの一つです。MVC for CSPMでは、現在以下の自動修復を提供することが可能です。主にストレージの公開権限の誤りの修正や、最小権限に基づいていないセキュリティグループの修正が提供されています。
|
Remediation Actions |
Policy Templates |
|
AES 256暗号化の適用 |
・Unencrypted S3 Buckets |
|
Public Permissionsの削除 |
・RDS Cluster Snapshot with Public Permissions ・RDS Snapshot with Public Permissions |
|
Public Read Accessの削除 |
・World Readable S3 Buckets |
|
制限の不十分なアクセス許可の削除 |
・Unrestricted CIFS Access ・Unrestricted DNS Access ・Unrestricted FTP Access ・Unrestricted MongoDB Access ・Unrestricted MSSQL Access ・Unrestricted MSSQL Database Access (UDP) ・Unrestricted MySQL Access ・Unrestricted NetBIOS Access ・Unrestricted Oracle Database Access ・Unrestricted PostgreSQL Access ・Unrestricted Remote Desktop Access ・Unrestricted RPC Access ・Unrestricted SMTP Access ・Unrestricted SSH Access ・Unrestricted Telnet Access ・Unrestricted VNC Listener Access ・Unrestricted VNC Server Access |
|
安全性が十分でないストレージのスキャン |
・Publicly Writable S3 Buckets ・Unrestricted Access to S3 Bucket ・World Readable S3 Buckets |
■実際の動作イメージ
せっかくなので、実際の設定例を見てみましょう。「Unrestricted CIFS Access」という設定監査ポリシーを利用して、意図せず「SMBポートが許可されているセキュリテイグループを検出したら違反設定を削除する」という自動修正を行ってみましょう。
・MVC for CSPMで自動修正ポリシーを作成する
MVC for CSPMでは、事前に準備された約400個の設定監査ポリシーを利用して様々なセキュリテイインシデントを検出することが可能です。以下の例では予め準備されていた「Unrestricted CIFS Access」というポリシーの設定画面です。IPv4とIPv6で送信元がAnyとなっていて、ポート番号が445(SMB)となっているセキュリテイグループを検出するように設定しています。
また、中にはSMBを明示的に許可しているシステムもあるため、監視除外設定としてAWS AccountIDが「Test」の物や、Tagとして「CASB-Audit = No」が定義されているEC2インスタンスは除外する設定となっています。
最後に「Responses」の箇所で違反が検出された時のアクションを指示しています。この例では「Remove Unrestricted Access」を指定し、違反設定を削除するように指示しています。
・AWS側に違反設定を登録する
次にAWS側にCIFSを許可するインバウンドルールを設定してみましょう。ソースIPをAnyで、TCPポート番号の445(SMB)を許可します。
・MVC側で自動修正が発生したかを確認する
MVC側でAWSの違反設定を検出出来ているかを確認します。
AWSのセキュリテイグループ名と違反と判定された所にビックリマークが付いていることがわかります。
・AWS側で違反設定が削除されたか確認する
最後にAWS側で違反設定が削除されていたかを確認します。TCP 445の違反設定が2行とも削除されていることがわかります。なお、今回はテストのため違反設定のみを定義していましたが、実際の環境では複数の通信許可設定が登録されているのが一般的です。その場合には、MVCはポリシー違反の行のみ削除し、その他の行は削除しません。ポリシー違反の行のみ安全に排除することが可能です。
■人間依存では設定ミスの排除は不可能
最近のAWSによるシステム構築ではシステム単位でAWSアカウントが払い出され、一つの企業の中に複数のAWSアカウントが乱立しているというのも珍しい状況ではありません。重要なシステムであれば十分にトレーニングを積んだAWS担当者がアサインされる可能性は高くなりますが、それほど重要ではない例えば社内のテスト環境等の場合、利用者側のセキュリティ意識は低くなりがちです。どれほど厳密なガイドラインを作成したとしても、人間が守るとは限りません。守ろうとしてもミスは起きます。
日々進化するAWSの機能に追随し、現場まかせで安全な状態を保つのは不可能です。そういった人依存のセキュリティ対策から一歩踏み出すのがCSPMソリューションです。
AWS等のIaaSを利用している方は、是非検討してみてはいかがでしょうか。