Conformityルールの紹介

[Is there any rule that looks for open access to all ports?]ルール: EC2-001 (Security Group Port Range)は、すべてのポートを含む開放ポートの範囲をチェックします。
[Are all the rules in AWS Config included in Conformity?] AWS Configのすべてのルールは、config:DescribeConfigRules APIを通じて利用可能になるとすぐにサポートされます

注意

Conformityが必要なRuleをサポートしていない場合、AWS Config Serviceを使用してカスタムルールを作成するオプションがあります。

新しいアカウント

アカウントが初めてConformityに追加されると、Conformity Botによってアカウントに対して一連のデフォルトルールが実行されます。

ルール構成

ルールは、組織の状況やガバナンスのニーズにより適したものに構成できます。一部のルールは実行前に構成が必要であり、すべてのルールには重大度の調整や有効化/無効化を含む構成オプションがあります。

ルール設定を参照してください。

Rule settings

一般的なルール設定 (新しいルールの動作やルールの構成など) は、Cloud Accountsレベルで管理できます。Rule settingsを参照してください。

ルールの構造

Conformityルールは、AWS (または他のクラウドプロバイダ) やConformityサービスに対して実行されます。例えば、Guard Duty、CloudTrail、Conformityです。サービスの完全なリストはKnowledge Baseで見つけることができます。

Conformityは、各Ruleに対してServiceおよびServiceリソースに対してChecksを実行します。Checksは[fail]または[succeed]することができ、Conformityの多数のreporting toolsによって記録されます。

注意

新しいルールまたは更新されたルールは、リリース後10日間適切にマークされます。

サマリーを確認

さまざまなチェックステータスのカウントを提供します。各ステータスの詳細については、モデル: チェックを参照してください。

Not Scored

Conformityは特定のルールに対してnot scoredステータスのチェックを作成します。not scoredチェックは、FailureまたはSuccessの条件を明確に評価できない場合の情報マーカーまたは通知です。これらは推奨される設定の手動監査を行うのに役立つ場合や、アカウント内のリソースに関する部分的な情報を提供する場合があります。

not scoredの可能性があるシナリオ

一部の推奨設定は特定のコンプライアンス基準に必要ですが、クラウドリソースメタデータのスキャンによって評価することが実用的でない、または不可能な場合があります。例えば、クラウドプロバイダからのAPIまたはSDKの応答に制限があると、ルールの開発が制限されることがあります。このシナリオでは、指定されたルールのアカウントチェックに単一のnot scoredチェックが保存される場合があります。
この推奨事項は、お使いのクラウドリソースの構成に直接適用されない場合があります。例えば、外部の構成やクラウドリソースのメタデータレベルでは評価されないリソース内の内部設定に関連している場合があります。
追加のコンテキスト情報が必要で、FailureまたはSuccessの条件を完全に判断するために、自動チェックが部分的にしか実行できない場合があります。このシナリオでは、特定のクラウドリソースに関してnot scoredチェックが表示されることがあります。
情報の発見は、特定のクラウドネイティブサービスからnot scoredチェックとして取り込まれ、保存される場合があります。

詳細については、モデルチェックを参照してください。

非推奨ルール

Conformityによって削除対象としてマークされたルールは[Deprecated Rules]として識別されます。

[Why are rules marked for deprecation?]

将来削除される予定の[Deprecated Rule]が特定されました。これは、関連する推奨事項が無効になったか、他の推奨事項に取って代わられたか、別のRule推奨事項に組み込まれたためです。

[How do I know a rule is deprecated?]

ルールのタイトルおよび関連する[Knowledge Base]ページには、ルールが非推奨かどうかが反映されます。非推奨としてマークされたルールが設定されている場合、アカウントの[Rule Settings]および[Profile Settings]に警告メッセージが表示されます。

[What should I do if I have configured deprecated rules in an account?]

[Deprecated Rules]はデフォルト設定のままにしておいてください。これは、後でRuleが削除されたときにアカウントの中断を避けるために重要です。

非推奨のRuleが[Account Rule Settings]に設定されている場合、ダッシュボードから編集するには:

アカウントをクリックし、[Settings]、[Rule settings]に移動して、[Update rule settings]をクリックしてください
違反しているRuleを検索し、[Configure]をクリックしてください
ルール設定ウィンドウで、[Reset to default]をクリックします

[What should I do if I have configured deprecated rules in a Profile?]

非推奨のRuleが[Profile]に設定されている場合、ダッシュボードから編集するには:

[Profile]をクリックしてください
違反しているRuleを検索
[Reset]ボタンをクリックして、すべてのRule settingsを削除してください
ルール設定を削除してもよろしいかと尋ねられたら、[Yes, remove it]をクリックしてください

他の場所に保存されている[Profile] JSONファイルがある場合、廃止されたRuleに接続されているすべての構成を削除し、通常の[Profile]更新プロセスに従ってください。

[Rule Removal]

ルールがしばらくの間非推奨になった後、システムからルールを完全に削除します。中断がないようにするために、ルールをデフォルトの状態のままにしておくことを忘れないでください。

リアルタイム監視でサポートされるルール

[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	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
Organizations	組織-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	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]

サービス	ルール
ネットワーク	ネットワーク-014
ポリシー	ポリシー-001
SecurityCenter	SecurityCenter-026, SecurityCenter-027
Sql	Sql-016

[GCP]

サービス	ルール
CloudIAM	CloudIAM-014
CloudKMS	CloudKMS-003
クラウドストレージ	CloudStorage-004
ComputeEngine	ComputeEngine-012
CloudSQL	CloudSQL-029
CloudDNS	CloudDNS-004
クラウドロードバランシング	CloudLoadBalancing-003
GKE	GKE-003
リソースマネージャー	リソースマネージャー-004
CloudPubSub	CloudPubSub-001

[Conformity]

サービス	ルール
ユーザサインイン	RTM-004, RTM-006

よくある質問

手順

ConformityのWebインターフェースでルールが「新規」または「更新」としてマークされています。それはどういう意味ですか?
更新されたRuleおよび新しいRuleは、リリース後10日間「更新済み」および「新規」としてマークされます。更新には、Ruleの動作変更、バグ修正、改善、新しい設定、デフォルト設定の変更、デフォルトのリスクレベルの変更などが含まれます。
なぜAssumeRoleアクションがブラックリストに登録されたリージョンルールのFailureを引き起こすのですか?
時々、リージョンが前回のセッションからブラウザに引き継がれることがあります。例えば、ユーザの最後のアクションがus east 1だった場合、次回ユーザがログインすると、通常はeu west 1にログインする場合でも、コンソールログインがus east 1になることがあります。
S3バケットで静的ウェブサイトホスティングオプションがオンになっているかどうかを確認するRuleはありますか?静的ウェブサイトホスティングをオンにしてバケットを作成しましたが、違反は発生しませんでした。
リンクを参照してください: ウェブサイト構成が有効なS3バケット
AWS Inspectorの検出結果のリスクレベルはConformityによってどのように計算されますか?AWS Inspector Findingsのリスクレベルは以下のように計算されます: Inspector.severity = 高; Conformityリスクレベル = 高Inspector.severity = 中; Conformityリスクレベル = 中Inspector.severity = 低; Conformityリスクレベル = 低それ以外の場合、Conformityリスクレベル = 低
GuardDutyの検出結果のリスクレベルはConformityによってどのように計算されますか?

GuardDutyの検出結果のリスクレベルは次のように計算されます。

GuardDuty.level >=7.0; Conformityリスクレベル = 高

GuardDuty.level >=4.0 & GuardDuty.level <=6.9; Conformityリスクレベル = 中

その他のConformityリスクレベル = 低
ConformityによってMacie Alertsのリスクレベルはどのように計算されますか?
Macieアラートのリスクレベルは次の方法で計算されます:

Macie.severity = Critical; Conformityリスクレベル = Extreme

Macie.severity = 高; Conformityリスクレベル = 高

Macie.severity = 中; Cloud Conformityリスクレベル = 中

Macie.severity = 低; Cloud Conformityリスクレベル = 低

Macie.severity = Informational; Cloud Conformityリスクレベル = 低
複数の信頼できるアカウントを追加するのは非常に時間がかかるプロセスです。もっと良い方法はありますか?
複数の信頼されたアカウントを追加する場合は、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証明書更新Rule-2,3,4のうち、任意の時点で重複を避けるためにチェックを生成するのは1つだけです

a. ACM-002証明書は7日以内に期限切れになります

b. ACM-003証明書は7日から30日以内に期限切れになります

c. ACM-004証明書は30日から45日の間に期限切れになります

任意の時点でACM-002、ACM-003、ACM-004のうち1つのチェックを行う理由は、重複を避け、信頼性の高いConformityスコアを作成するためです。

ACM-002はHigh Riskです

ACM-003は中リスクです

ACM-004は低リスクです

45日から30日の間に低リスクチェックを受け取り、30日から7日の間に中リスクチェックを受け取り、最終的に7日から有効期限までの間にHigh Riskチェックを受け取ります。
CloudTrailがS3にログを記録するように設定されているかどうかを検出するルールはありますか?
はい。CloudTrail Enabled ruleは、CloudTrailがS3にログを記録するように設定されているかどうかを検出します。トレイルを設定するにはS3BucketNameが必要です。
ホワイトリストに登録されていないユーザのログオンを確認することは可能ですか?
サインインイベントルールは、IAMおよびフェデレーティッドユーザのサインインイベントをチェックします。また、ユーザが承認された国からAWSにサインインしましたルールは、承認されていない国からのユーザ認証セッションを検出します。
RDSスナップショットが公開されているかどうかを検出することは可能ですか?
はい。Amazon RDS Public Snapshotsルールは、すべてのパブリックRDSスナップショットを検出します。
EC2インスタンスからCloudWatchログをエクスポートしてアラートを生成できますか?
ConformityはCloudWatchログにアクセスできないため、EC2インスタンスからのアラートを生成できません。
RTM-004とRTM-006はCloud Oneユーザに対して実行されますか?
ルール RTM-004 (Cloud ConformityユーザがMFAなしでサインイン) およびRTM-006 (Usersが承認された国からCloud Conformityにサインイン) はStandalone Conformityのみで実行され、Cloud Oneユーザには実行されません。

次に進む前に

Cloud Sentry よくある質問

[Q: What are the Conformity rule exceptions for Cloud Sentry and why?]

Cloud Sentry機能は、クラウド構成のベストプラクティスを満たすために、セキュリティおよびパフォーマンスを含む徹底的なテストを受けました。次のルールの失敗が発生する可能性があります:

[Lambda-009 - Enable Encryption at Rest for Environment Variables using Customer Managed Keys]: Sentryリソースはデフォルトキーで安全に暗号化されています。さらに、環境変数には秘密情報が含まれていないため、顧客管理キーを使用した追加の暗号化は必要ありません。
[SecretsManager-001 - Secret Encrypted With KMS Customer Master Keys]: Sentryリソースはデフォルトキーで安全に暗号化されているため、顧客管理キーを使用した追加の暗号化は必要ありません。
[Lambda-001: Lambda Using Latest Runtime Environment]: Sentryは、すべてのLambdaがサポートされているランタイム環境を使用し、サポート終了日がないことを保証します。すべてのサポートされているランタイム環境は、AWSから頻繁にセキュリティアップデートを受け取ります。
[Lambda-003 Lambda Tracing Enabled]: Sentryはこの機能がリリース前に徹底的にテストされることを保証するため、トレースの有効化による追加の可視性は必要ありません。
[SecretsManager-002:Secret Rotation Enabled]: SentryはAWSが提供するものではなく独自のシークレット機能を使用しているため、AWSが提供するシークレットローテーション機能を有効にする必要はありません。
[SecretsManager-003: Secret Rotation Interval]: SentryはAWSが提供するものではなく独自のシークレット機能を使用しているため、AWSが提供するシークレットローテーション機能を有効にする必要はありません。
[S3-024:S3 Transfer Acceleration]: Sentry機能は転送加速機能を使用しません。
[Lambda-006: Using an IAM Role For More Than One Lambda Function]: Sentryは「permission planes」と呼ばれる戦略を採用しており、同一の権限を必要とするLambda関数が単一のIAM Roleを使用します。これにより、複数のリージョンにデプロイする際の効率性と管理性が確保されます。例えば、顧客のCloud Accountで使用されるIAM Roleの数が減少します。
[Lambda-007:VPC Access for AWS Lambda Functions]: Sentryは、VPCの実装が必要となる可能性があるRedshift、ElastiCache、RDSなどのリソースを使用しません。
[CFM-001: CloudFormation Stack Notification]: Sentry CloudFormationスタックは、AWSではなくV1 CAMを介して既に管理されています。
[CFM-002: CloudFormation Stack Policy]: Sentry CloudFormationスタックは、AWSではなくV1 CAMを介して既に管理されています。
[CFM-005:CloudFormation Stack Termination Protection]: 環境内のスタックを管理するために、Sentryはユーザがスタックを無効化し、アカウントから削除することを許可しています。
[S3-025: S3 Buckets Encrypted with Customer Provided Keys CMKs]: SentryはすでにS3管理キーを使用して暗号化されています。
[SQS-006:SQS Dead Letter Queue]: Sentryは、適用可能な場合にいくつかのSQSリソースでデッドレタキュー (DLQ) を実装します。
[S3-013: S3 Bucket MFA Delete Enabled]: Sentry用にS3に保存されるオブジェクトは比較的短命であり、すべての削除アクションにMFAを必要とすることは、Sentry機能を使用する顧客の運用負担を大幅に増加させます
[S3-023: S3 Object Lock]: Sentry用にS3に保存されたオブジェクトは比較的短命であり、特定のオブジェクトをロックすると、Sentryライフサイクルオブジェクトのライフサイクルおよび削除Policiesに影響を与えます

[What to do next?]

これらの失敗がクラウドアカウントのコンプライアンスに影響を与えないようにするために、上記のルールからSentryリソースを除外し、リソースタグを使用してルール除外を作成できます。ルールの失敗はSentryリソースによって引き起こされ、リソースタグ - AppManagerCFNStackKey: C1 Sentry を使用してルール除外を簡単に管理できます。次の2つの方法で行います:

手順

タグを使用してRule例外を設定する
プロファイルを使用

2.1. プロファイルを作成

2.2. 新しいProfileを設定し、Ruleの例外を追加します。

2.3. Profileをアカウントに適用する。

2.4. [Overwrite]ウィンドウで > [Include Exceptions]を選択 > Profileをマージして、ルールの例外を適用するアカウントを選択します。

Organization Profileを設定して、これらの設定をOrganization内のすべてのアカウントに適用し、デフォルトのRule settingsを上書きすることもできます。