このページのトピック
Conformity ルールの概要
コンテンツ
Conformity はどのようなルールをサポートしていますか?
Trend Micro Cloud One™– Conformity はどのようなルールをサポートしていますか?
Conformity は、クラウドおよびセキュリティガバナンスのベストプラクティスに基づいた 540 ルール 、および コンプライアンス標準をサポートします。
Conformityのルールは、セキュリティおよび管理のベストプラクティスの 6カテゴリ を対象としています。
- セキュリティ
- Cost Optimisation
- 優れた運用性
- 信頼性
- パフォーマンスの効率
- 持続可能性
ルールは、クラウドアカウントサービス、リソース、それらの設定、および 設定に対して実行されます。
ルールの実行頻度
Conformity ルールは次のように実行されます。
- 追加されたアカウントに定期的に、Conformity Botによって、または
- リアルタイム監視サブスクリプションアカウントでオンになっている場合は、選択したルールについてリアルタイムで。
実行されるルール
Conformityでサポートされるすべてのルールについては、 Conformity Knowledge Base を参照してください。
- すべてのポートへのオープンアクセスを検索するルールはありますか? Rule: EC2-001(セキュリティ Group ポート範囲) は、すべてのポートを含むオープンポートの範囲をチェックします。
- AWS Config のすべてのルールが Conformityに含まれていますか? AWS Config のすべてのルールは、
config:DescribeConfigRules
APIを介して利用可能になった時点でサポートされます。
Conformity が必要なルールをサポートしていない場合は、 AWS Config サービスを使用してカスタムルールを作成することもできます。 {: .note }
新しいアカウント
Conformityにアカウントが最初に追加されると、 Conformity Botによって一連の初期設定ルールがアカウントに対して実行されます。
ルール設定
組織の状況や管理ニーズに合わせてルールを設定できます。一部のルールは実行前に設定が必要で、すべてのルールには重要度の調整や有効化/無効化などの設定オプションがあります。
Rule Configurationを参照してください。
ルール設定
Cloud Accounts レベルで管理できる共通のルール設定(新しいルールの動作やルール設定など)があります。 Rule settingsを参照してください。
ルールの構造
Conformityルールは、AWS (または他のクラウドプロバイダ) またはConformityサービスに対して実行されます。たとえば、Guard Duty、 CloudTrail、 Conformityなどです。サービスの完全なリストについては、Knowledge Base を参照してください。
Conformityは、Ruleが属しているサービスおよび/またはサービスリソースに対して、RuleごとにChecksを実行します。Checkは、失敗または 成功し、Conformityの多数の レポートツールによって取得されます。
注意:新しいルールまたはアップデートされたルールには、リリース後10日間のマークが付けられます。
Checksの概要
さまざまなチェックステータスをカウントします。各ステータスの詳細については、「 モデルのCheck」を参照してください。
スコアなし
Conformityは、特定のルールに対してステータスが「スコアなし」のチェックを作成します。 「スコアなし」チェックは、FailureまたはSuccessの条件を明示的に評価できない場合の情報マーカーまたは通知です。推奨設定を手動で監査したり、アカウント内のリソースに関する部分的な情報を提供したりする場合に役立ちます。
「スコアなし」の可能性のあるシナリオ
- 一部の推奨事項は、特定のコンプライアンス標準に必要ですが、実際的ではない場合や、クラウドリソースメタデータのスキャンで評価できない場合があります。たとえば、クラウドプロバイダからのAPIまたはSDKの応答に関する制限により、ルールの開発が制限される場合があります。このシナリオでは、特定のルールのアカウントチェックに「Not Scored」チェックが保存されます。
- 推奨事項は、クラウドリソースのメタデータレベルでは評価されないリソース内の外部設定または内部設定に関連する場合など、クラウドリソースの設定に直接適用できない場合があります。
- FailureまたはSuccessの条件を完全に判断するために追加のコンテキスト情報が必要な場合など、関連する自動チェックは部分的にしか実行できない場合があります。このシナリオでは、特定のクラウドリソースに関して「スコアなし」チェックが表示されることがあります。
- 特定のクラウドネイティブサービスから情報結果が取り込まれ、「スコアなし」チェックとして保存される場合があります。
詳細については、「モデルチェック」を参照してください。
非推奨のルール
Conformity によって削除対象としてマークされたルールは、 Deprecated Rulesとして識別されます。
ルールが廃止予定とマークされているのはなぜですか?
Deprecated Rule は、関連する推奨が無効になっているか、別の推奨に置き換えられているか、別のルール推奨に組み込まれているため、今後削除するために識別されました。
廃止予定のルールを確認する方法
ルールのタイトルと関連するKnowledge Baseページには、ルールが廃止されているかどうかが反映されます。 非推奨としてマークされたルールが設定されている場合、アカウントの Rule Settings 、および Profile Settings に警告メッセージが表示されます。
アカウントで廃止されたルールを設定した場合はどうすればよいですか?
Deprecated Rules は初期設定のままにします。これは、後でルールが削除されたときにアカウントが中断されないようにするために重要です。
Account Rule Settingsで非推奨のルールが設定されている場合、ダッシュボードを使用して次のルールを編集します。
- アカウントをクリックして、 Settings Rule settings に移動し、 Update rule settingsをクリックします。
- 問題のあるルールを検索し、[Configure] をクリックします。
- ルールの設定画面で、Reset to defaultの順にクリックします。
Profileで非推奨のルールを設定した場合の対処
Profileで非推奨のルールが設定されている場合、ダッシュボードで編集するには:
- Profileをクリックします。
- 問題のあるルールの検索
- Resetボタンをクリックして、ルール設定を削除します。
- ルール設定を本当に削除するかどうかを確認するメッセージが表示されたら、はい、削除しますをクリックします。
Profile JSONファイルが別の場所に保存されている場合は、非推奨のルールに接続されているすべての設定を削除し、通常の Profile アップデートプロセスに従います。
Ruleの削除
ルールのサポートが終了した後、システムからルールを完全に削除します。中断が発生しないようにするには、ルールを初期設定の状態のままにしてください。
リアルタイム監視でサポートされるルール
AWS
サービス | ルール |
---|---|
バックアップ | バックアップ-001 |
CloudFormation | CFM-001、CFM-002、CFM-004、CFM-005、CFM-006、CFM-007 |
CloudFront | CF-002、CF-003、CF-004、CF-005、CF-006、CF-007、CF-008、CF-009、CF-011 |
CloudTrail | CT-013 |
設定 | Config-005 |
DynamoDB | DynamoDB-001、DynamoDB-003、DynamoDB-004、DynamoDB-005 |
EC2 | EC2-001、EC2-002、EC2-003、EC2-004、EC2-005、EC2-006、EC2-007、EC2-008、EC2-014、EC2-015、EC2-016、EC2-017、EC2-020、EC2-021、EC2-022、EC2-023、EC2-024、EC2-025、EC2-026、EC2-027、EC2-028、EC2-029、EC2-030、EC2-031、EC2-032、EC2-033、EC2-034、EC2-035、EC2-036、EC2-038、EC2-039、EC2-040、EC2-041、EC2-042、EC2-043、EC2-044、EC2-045、EC2-046、EC2-047、EC2-053、EC2-055、EC2-056、EC2-058、EC2-059、EC2-061、EC2-063、EC2-064、EC2-065、EC2-066、EC2-069、EC2-070、EC2-071、EC2-072、EC2-073、EC2-074、EC2-075 |
ECS | ECS-001 |
ELB | ELB-001、ELB-002、ELB-003、ELB-004、ELB-005、ELB-006、ELB-007、ELB-008、ELB-009、ELB-010、ELB-011、ELB-012、ELB-013、ELB-014、ELB-015、ELB-016、ELB-017、ELB-018、ELB-021、ELB-022 |
GuardDuty | GD-003 |
IAM | IAM-001、IAM-002、IAM-003、IAM-004、IAM-005、IAM-006、IAM-007、IAM-008、IAM-009、IAM-010、IAM-011、IAM-012、IAM-013、IAM-016、IAM-017、IAM-018、IAM-019、IAM-020、IAM-021、IAM-022、IAM-024、IAM-025、IAM-026、IAM-027、IAM-028、IAM-029、IAM-033、IAM-038、IAM-044、IAM-045、IAM-049、IAM-050、IAM-051、IAM-052、IAM-053、IAM-054、IAM-056、IAM-057、IAM-058、IAM-059、IAM-060、IAM-062、IAM-064、IAM-069、IAM-071、RTM-001、RTM-002、RTM-003、RTM-005、RTM-008、RTM-010 |
KMS | KMS-007 |
Lambda | Lambda-001、Lambda-002、Lambda-003、Lambda-004、Lambda-005、Lambda-006、Lambda-007、Lambda-009 |
Macie | Macie-002 |
その他 | Misc-001, RTM-011 |
組織 | 組織-003 |
RDS | RDS-001、RDS-002、RDS-003、RDS-004、RDS-005、RDS-006、RDS-007、RDS-008、RDS-009、RDS-010、RDS-011、RDS-012、RDS-013、RDS-019、RDS-022、RDS-023、RDS-025、RDS-026、RDS-030、RDS-031、RDS-032、RDS-033、RDS-034、RDS-035、RDS-036、RDS-037、RDS-038、RDS-039、RDS-040、RDS-041、RDS-042 |
Route53 | Route53-009 |
Route53Domains | Route53Domains-001 |
S3 | S3-001、S3-002、S3-003、S3-004、S3-005、S3-006、S3-007、S3-008、S3-009、S3-010、S3-011、S3-012、S3-013、S3-014、S3-015、S3-016、S3-017、S3-018、S3-019、S3-020、S3-021、S3-022、S3-023、S3-024、S3-025、S3-026、S3-028 |
セキュリティハブ | SecurityHub-001 |
SSM | SSM-003 |
VPC | VPC-001、VPC-004、VPC-005、VPC-006、VPC-010、VPC-011、VPC-012、VPC-013、VPC-014、VPC-015、VPC-016、RTM-009 |
EKS | EKS-001, EKS-003 |
ECR | ECR-003 |
Azure
|サービス|ルール| |--- |--- | |Network|Network-014| |Policy|Policy-001| |SecurityCenter|SecurityCenter-026, SecurityCenter-027| |Sql|Sql-016|
GCP
サービス | ルール |
---|---|
CloudIAM | CloudIAM-014 |
CloudKMS | CloudKMS-003 |
CloudStorage | CloudStorage-004 |
ComputeEngine | ComputeEngine-012 |
CloudSQL | CloudSQL-029 |
CloudDNS | CloudDNS-004 |
CloudLoadBalancing | CloudLoadBalancing-003 |
GKE | GKE-003 |
ResourceManager | ResourceManager-004 |
CloudPubSub | CloudPubSub-001 |
Conformity
|サービス|ルール| |--- |--- | |ユーザサインイン|RTM-004, RTM-006|
よくある質問
- Conformity Webインタフェースで、ルールが「New」または「Updated」としてマークされています。どういう意味ですか?
アップデートされたルールと新しいルールは、リリース後10日間は「アップデート済み」および「新規」としてマークされます。アップデートには、ルールの動作の変更、バグ修正、改善、新しい設定、初期設定の変更、初期設定のリスクレベルの変更などが含まれます。 - 拒否リストに登録されたリージョンのルールでAssumeRole処理がFailureをトリガするのはなぜですか?
前回のセッションでブラウザがリージョンを取得する場合があります。ユーザの最後の処理がus east 1だったとします。ユーザが次回にログインしたとき、ユーザが通常はeu west 1にログインしていても、コンソールログインがus east 1になることがあります。 - 静的WebサイトホスティングオプションがオンになっているS3バケットを確認するルールはありますか?静的なWebサイトホスティングを有効にした状態で バケット を作成しましたが、違反がトリガされませんでした。
次のリンクを参照してください: Webサイト設定が有効なS3バケット - AWS Inspector Findingsのリスクレベルは、 Conformityでどのように計算されますか?
AWS Inspector Findings のリスクレベルは次のように計算されます。
Inspector.severity = High; Conformity リスクレベル= HIGH
Inspector.severity = Medium; Conformity リスクレベル= MEDIUM
Inspector.severity = Low; Conformity リスクレベル= LOW
それ以外の場合、 Conformity リスクレベル= LOW - ConformityによるGuardDutyの検出結果のリスクレベルの計算方法
GuardDuty Findings のリスクレベルは次のように計算されます。
GuardDuty.level >=7.0; Conformity リスクレベル= HIGH
GuardDuty.level>=4.0&GuardDuty.level<= 6.9; Conformity リスクレベル= MEDIUM
それ以外の場合、 Conformity リスクレベル= LOW - ConformityによるMacieアラートのリスクレベルの計算方法
Macieアラートのリスクレベルは次のように計算されます。
Macie.severity = Critical; Conformity リスクレベル= EXTREME
Macie.severity = High; Conformity リスクレベル= HIGH
Macie.severity = Medium; Cloud Conformity リスクレベル= MEDIUM
Macie.severity = Low; Cloud Conformity リスクレベル= LOW
Macie.severity = Informational; Cloud Conformity リスクレベル= LOW - 信頼するアカウントを複数追加する処理は、非常に時間がかかります。より良い方法はありますか?
複数の信頼済みアカウントを追加する場合は、 Conformity APIを使用できます。信頼するアカウントは、クロスアカウントルールの一部です。例 https://www.cloudconformity.com/knowledge-base/aws/SQS/sqs-cross-account-access.html アップデートルール設定エンドポイントを使用できます。https://github.com/cloudconformity/documentation-api/blob/master/Accounts.md#update-rule-setting - 最近有効期限が切れたACM証明書に関する問題が発生しました。 Conformity には、有効期限までの7日間(ACM-002)、30日間(ACM-003)、および45日間(ACM-004)のルールがあることがわかっています。しかし、ダッシュボードにアクセスしてACMサービスでフィルタすると、ACM-004しか表示されません。Cloud Conformity アカウントがすべてのACM証明書の有効期限ルールをチェックしているかどうかを確認したいだけです。チェックされている場合、ACMでフィルタしたときに表示されない理由を説明してください。
ACM 証明書更新ルールの1つのみ-重複を避けるために、2,3,4で任意の時点で Check を生成します。
a. ACM-002 証明書の有効期限は7日以内です
b. ACM-003 証明書の有効期限は7〜30日です
c. ACM-004 証明書の有効期限は30〜45日です
ACM-002、ACM-003、ACM-004から1つのCheck outを常に生成するのは、重複を回避して信頼性の高い適合スコアを作成するためです。
ACM-002はリスク高
ACM-003のリスクは中
ACM-004のリスクは低い
45〜30日でリスクの低いチェックを受け取ります。 30〜7日でリスクチェックが中程度。最終的には、7日から有効期限までの間にリスクの高いチェックが実行されます。 - CloudTrailがS3にログ記録するように設定されているかどうかを検出するルールはありますか?
はい。CloudTrail有効化ルール は、CloudTrailがS3にログ記録するように設定されているかどうかを検出します。トレイルの設定にはS3BucketNameが必要です。 - ホワイトリストに登録されていないユーザからのログオンを確認することはできますか?
Sign-In Events ルールは、IAMおよびフェデレーションUsersのサインインイベントを確認します。また、承認された国からAWSにサインインしたユーザ ルールによって、未承認の国からのユーザ認証セッションが検出されます。 - RDSスナップショットが公開されているかどうかを検出できますか?
はい。 Amazon RDS Public Snapshots ルールは、パブリックRDSスナップショットを検出します。 - CloudWatchのログをEC2インスタンスからエクスポートしてアラートを生成できますか?
ConformityはCloudWatchログにアクセスできないため、EC2インスタンスからアラートを生成できません。 - RTM-004およびRTM-006はCloud Oneユーザに対して実行できますか?
RTM-004 (Cloud ConformityユーザがMFAなしでサインインしている) およびRTM-006 (承認された国からCloud Conformityにサインインしているユーザ) は、スタンドアロンConformityに対してのみ実行され、 Cloud Oneユーザに対しては実行されません。
Cloud Sentry よくある質問
Q: Cloud SentryのConformityルール例外とは何ですか、それはなぜですか?
Cloud Sentry機能は、クラウド構成のベストプラクティスを満たすために、セキュリティおよびパフォーマンスを含む徹底的なテストを受けました。次のルールの失敗が発生する可能性があります:
- Lambda-009 - Customer managed keysを使用して環境変数の保存時の暗号化を有効にする: Sentryリソースはデフォルトキーで安全に暗号化されています。さらに、環境変数には秘密情報が含まれていないため、Customer managed keysを使用した追加の暗号化は必要ありません。
-
SecretsManager-001 - KMSカスターマスターキーで暗号化されたシークレット: Sentryリソースはデフォルトキーで安全に暗号化されているため、顧客管理キーを使用した追加の暗号化は必要ありません。
-
Lambda-001: 最新のランタイム環境を使用するLambda: Sentryは、すべてのLambdaがサポートされているランタイム環境を使用し、サポート終了日がないことを保証します。すべてのサポートされているランタイム環境は、AWSから頻繁にセキュリティアップデートを受け取ります。
-
Lambda-003 Lambdaトレースが有効: Sentryはこの機能をリリース前に徹底的にテストするため、トレースを有効にすることで追加の可視性は必要ありません。
-
SecretsManager-002:シークレットのローテーションが有効: SentryはAWSが提供するものではなく独自のシークレット機能を使用しているため、AWSが提供するシークレットローテーション機能を有効にする必要はありません。
-
SecretsManager-003: シークレットローテーション間隔: SentryはAWSが提供するものではなく独自のシークレット機能を使用しているため、AWSが提供するシークレットローテーション機能を有効にする必要はありません。
-
S3-024:S3 Transfer Acceleration: Sentry機能は転送加速機能を使用していません。
-
Lambda-006: 複数のLambda関数に対してIAM Roleを使用する: Sentryは、同一の権限を必要とするLambda関数が単一のIAM Roleを使用する「permission planes」と呼ばれる戦略を採用しています。これにより、複数のリージョンにデプロイする際の効率性と管理性が確保されます。例えば、顧客のCloud Accountで使用されるIAM Roleの数を減らすことができます。
-
Lambda-007:AWS Lambda関数のVPCアクセス: Sentryは、VPCの実装が必要なRedshift、ElastiCache、RDSのようなリソースを使用しません。
-
CFM-001: CloudFormationスタック通知: Sentry CloudFormationスタックは既にAWSではなくV1 CAMを通じて管理されています。
-
CFM-002: CloudFormationスタックポリシー: Sentry CloudFormationスタックは、AWSではなくV1 CAMを介して既に管理されています。
-
CFM-005:CloudFormationスタック終了保護: 環境内のスタックを管理するために、Sentryはユーザがスタックを無効化し、アカウントから削除することを許可しています。
-
S3-025: 顧客提供のキーCMKで暗号化されたS3バケット: SentryはすでにS3管理キーを使用して暗号化されています。
-
SQS-006:SQSデッドレターキュー: Sentryは、該当する場合にいくつかのSQSリソースでデッドレターキュー (DLQ) を実装します。
-
S3-013: S3バケットMFA削除有効: Sentry用にS3に保存されているオブジェクトは比較的短期間であり、すべての削除アクションにMFAを必要とすることは、Sentry機能を使用する顧客にとって運用の手間を大幅に増加させます
-
S3-023: S3オブジェクトロック: Sentry用にS3に保存されたオブジェクトは比較的短命であり、特定のオブジェクトをロックすると、Sentryライフサイクルオブジェクトのライフサイクルおよび削除Policiesに影響を与えます
次に何をすべきですか?
これらの失敗がクラウドアカウントのコンプライアンスに影響を与えないようにするために、上記のルールからSentryリソースを除外してください。リソースタグを使用してルール除外を作成できます。ルールの失敗はSentryリソースによって引き起こされ、リソースタグを使用したルール除外で簡単に管理できます - AppManagerCFNStackKey: C1 Sentry
以下の2つの方法で:
- ルールの除外設定 タグを使用する
-
プロファイルの使用
2.1. プロファイルの作成
2.2. ルールの除外設定を使用して新しいプロファイルを設定する
2.3. **アカウントにプロファイルを適用する**
2.4. [Overwrite] ウィンドウで、[Include Exceptions]→[Merge Profile] を選択し、ルールの除外を適用するアカウントを選択します。
また、ルール例外を使用してこれらの設定を組織内のすべてのアカウントに適用し、デフォルトのルール設定を上書きするためにOrganization Profileを設定 することもできます。