この機能により、ユーザは既存のチェックを新しく作成されたコミュニケーションチャネルに一括で取り込むことができます。新たに発見されたチェックや更新されたチェックは、有効化された自動通知を通じてコミュニケーションチャネルに自動的に転送されるため、これは一度限りの操作であることが期待されています。
なぜ履歴チェック通知を再実行するのですか?
この機能を使用すると、既存の自動通知の動作を補完し、ユーザがターゲットの通信チャネルに過去のチェック (通信チャネルの作成前に発見されたチェック) を再実行できるようになります。これは、ユーザがチケットチャネルで過去のチェックを追跡したい場合に役立ち、通信チャネルが提供する自動解決機能を利用してチケットを解決することができます。
APIエンドポイント:
サポートされている通信チャネル
- Jira
- ServiceNow
- Zendesk
- AWS SNS
- Webhook
重要:
- チケット管理チャネル (Jira、ServiceNow、Zendesk) では、チェックがすでにチケット管理チャネルに関連付けられている場合、履歴チェックを再実行しても重複したチケットは作成されません。
- チケット発行以外のチャネル (AWS、SNS、Webhook) では、エンドポイントが呼び出されるたびにチェックが再送信されます。
- この機能は現在、アカウントレベルの通信チャネルのみをサポートしています。
- 指定されたアカウント (通信設定が構成されているもの) への書き込みアクセス権を持つユーザのみがこのエンドポイントを使用できます。
- リクエストが成功した後、通知が通信チャンネルに表示されるまで数分かかる場合があります。
- 設定された通信チャネルのトリガーに基づいて、ターゲット通信チャネルに送信された過去のチェックはフィルタリングされます。
ユーザシナリオ
-
非常に推奨されるのは、通信チャネルにいくつかのトリガーを設定することです。詳細についてはこちらをご覧ください。
-
APIエンドポイントは、
newerThanDaysまたはolderThanDaysの2つのフィルターを受け入れます。通信チャネルの作成または更新時間に近い時間枠をお勧めします。どのチェックを行いたいかのアイデアを得るには、Cloud Risk Management UIの[Browse All Checks]セクションでフィルターを設定できます。 -
例: 自動通知通信チャネルが今日から30日前に作成された場合、
olderThanDays30 のフィルターは、その通信チャネルの作成前の履歴チェックを提供します。
例
AWS accountをオンボードし、コンプライアンス検索が最初の検索を完了したと仮定し、Jiraチケットシステムが設定されていない場合。
[Browse All Checks]を訪問すると、S3 bucketリソースが2つの失敗を作成したことがわかります。ユーザとして、これらの失敗チェック通知がJiraチケットシステムに配信されることを望んでいます。
すべての履歴チェック通知を取得するには、新しいJiraチケットコミュニケーションチャネルを作成し、自動通知を有効にして、次のトリガーを適用します。
- サービス: S3
- リスクレベル: 極端、非常に高い、高
- タグ:「staging」と「demo」
PostmanでAPIエンドポイントを使用する:
失敗したチェックがJiraに正常にインポートされたことを表示しています。
それらの不具合に対処した後、Jiraの通信における自動通知が作成された2つのチケットを解決します。
