【汎用的だよ】CLOUD SECURITY POSTURE REPOSITORYでDome9の事前定義ルールを確認する

中山（順）です

クラスメソッドではCLOUD SECURITY POSTURE MANAGEMENT（以下、CSPM）の機能を提供するSaaSとしてDome9を扱っています。 CSPMとは、クラウドサービスの設定に含まれるリスクやコンプライアンス違反を検出・修正したり、それを継続的に行うことです。 能動的にリスク管理を行うことでセキュリティインシデントの発生を予防できます。 Dome9では、管理対象としてAWS/Azure/GCP/Kubernetesをサポートしています。

そもそもどんな設定がリスキーなの？

Dome9では、CLOUD SECURITY POSTURE REPOSITORY（以下、CSPR）としてDome9上で事前定義されている評価ルールを公開しています。 これは誰でも参照することが可能です。

CLOUD SECURITY POSTURE REPOSITORY (CSPR)

見て頂くと分かると思うのですが、評価ルール自体は汎用的な内容なのでDome9を利用しない方にも活用頂けるような内容になっています。

ここからは、どんな情報を確認できるか紹介していきます。

サポートしているプラットフォーム

前述の通り、Dome9では以下のプラットフォームをサポートしています。

• AWS(Amazon Web Services)
• Azure(Microsoft Azure)
• GCP(Google Cloud Platform)
• Kubernates

以下の通り、タブでプラットフォームを切り替えることができ、プラットフォーム別のルールを確認することができます。

フィルタ

画面左側にはフィルターが用意されています。

フィルタで利用できる属性は以下の5つです。

• Risk Level
• Domain
• Remediation - Cloudbots Assigned
• Service/Entity Category
• Entity

Risk Levelは、文字通りリスクの大きさを示す属性です。 CSPMを始めるにあたって、まずはHighRiskの検知と是正から始めるというアプローチもアリではないかと思います。

Domainでは設計要素で分類できます。 具体的には、"Encryption and Key Management", "Network Security", "Logging", "Identity and Access Management", "Monitoring", "Operational", "Cloud Assets Management", "Vulnerability and Threat Management", "Backup and Disaster Recovery", "Domain Name System (DNS) Management", "Network Ports Security"でフィルタリングできます。 特に重視したいDomainのみを評価したときに利用できるでしょう。

Remediation - Cloudbots Assignedは、Dome9の機能で検出されたリスクを自動的に是正できるかを示す属性です。 Dome9では検出したリスクを自動で修正する機能を提供しています。 詳細は以下の記事を参照してください。

Service/Entity Categoryは、評価対象のリソースがどのカテゴリーに属するかを示す属性です。 データ保護を重視してルールを絞り込むのであれば、"Compute", "Database", "Networking & Content Delivery", "Security, Identity, & Compliance", "Storage"などでフィルタリングするとよいのではないかと思います。

Entityは、Service/Entity Categoryより細かいリソースの種類を示す属性です。 評価対象のリソースが明確な場合に利用するとよいのではないかと思います。 AWSに存在する全てのリソースをサポートしているわけではありませんが、代表的なものは一通り含まれているかと思います。

ルールの詳細

最後に、各ルールの中身を確認してみましょう。 今回は、以下のルールを例として取り上げますが、ドキュメントの構成は基本的に同じです。

ENSURE NO SECURITY GROUPS ALLOW INGRESS FROM 0.0.0.0/0 TO SSH (TCP:22)

まずタイトルですが、「どうあるべきか」がルール名になっています。 このルールでは、「任意のIPアドレスからSSH(TCP:22)でのアクセスを許可しているSecurityGroupが存在しないこと」という表現になっています。

次に、ルールの概要が記述されています。 そもそもSecurityGroupが何なのかということと、SecurityGroupがどうあるべきかが簡単に述べられています。

次に、GSL LOGICという評価式が記載されています。 これはDome9独自の言語で、宣言的にリスクの有無を評価する式を記述できます。 詳細は以下のドキュメントを参照してください。

The CloudGuard Dome9 GSL Language

独自の文法ではありますが、見て頂いたとおり非常にわかりやすいので学習コストは非常に小さいのではないかと思います。 また、GSL Builderとして評価式の作成を支援する機能が管理コンソール上で提供されています。

次に、REMEDIATIONではリスクの是正手順が説明されています。 この例では、リスクのあるInboundルールを削除する手順が示されています。

次に、AUTO REMEDIATION USING CLOUDBOTSでは自動での是正ロジックが説明されています。 このルールでは、2つの注意事項が記載されています。

一つ目は、TCP:22以外の範囲も1つのルールで許可している場合です。 リスクがあるとされたルールをまるごと削除するのか、TCP:22を含まない範囲を新たなルールとして追加し直すのか選択できることが記載されています。

二つ目は、全てのポートでのアクセスを許可している場合です。 その場合にはには無条件で削除の対象になることが記載されています。

CloudBotsを利用する際には、このあたりの仕様をよく確認してから利用するようにしましょう。 なんでもかんでも「よきに計らってくれる」わけではありません。

AWS SECURITY GROUPでは、Security Groupに関する解説が記載されています。 これについては書いてあるとおりです。

最後に、COMPLIANCE FRAMEWORKSではルールがどのSecurity Framework/Compliance Standardに対応しているかを表しています。 このルールは、Best Practice/HIPAA/ISO27001/NIST CSF/PCI DSSに対応しているとされています。

このように、GSLの言語仕様以外は非常に汎用的であり、Dome9を利用しない場合でもリファレンスとして利用できるのではないでしょうか？

まとめ

Dome9は継続的なコンプライアンス標準への準拠やリスクの緩和を支援するための強力なツールですが、その価値に見合ったお値段でもあります。 そのため小規模な環境では利用できない（予算の都合など）ケースがあると思います。

しかし、CLOUD SECURITY POSTURE REPOSITORYでは、クラウドサービスのリソースに含まれる一般的なリスクを網羅的に把握することができます。 まずはこれを参照してリスクの把握と是正を検討してみてはいかがでしょうか？ ビジネスが順調に成長してCSPMのために投資ができる状態になったら、Dome9のことを思い出して頂けると幸いです。

なお、CSPMを実現する他の選択肢としてはSecurity HubのSecurity Standardなどもあります。 サポートしているリソースが少なかったりルールの数が少なかったりしますが、CLOUD SECURITY POSTURE MANAGEMENTの第一歩としてはちょうどよいと思います。

Security Standards in AWS Security Hub

現場からは以上です。