管理Security posture

保存済みのSecurity postureのイベントを現在の結果と照合する

Copy page



1日に1回、SIEMに保存した表明のアクティビティをエンドポイントの現在の結果と比較し、どの不一致に人による対応が必要かを判断します。

アクティビティフィードはアクティビティを遅れて配信することがあり、エンドポイントは履歴を保持しません。そのため、どちらのソースにも、もう一方には表示されない変更が表示される可能性があります。日次の比較により、セキュリティ情報イベント管理（SIEM）のストアに欠けているものを見つけられます。フィードはすべての変更を記録するとは限りません。そのため、表明がそのセキュリティコントロールに対するフィードの最初のアクティビティよりも古い場合があり、まれに変更にアクティビティがまったくないこともあります。現在の結果のみを報告する場合、このチェックは必要ありません。

組織を対象とするCompliance Access Keyが必要です。エンドポイントにはread:compliance_org_data、アクティビティフィードにはread:compliance_activities、または両方に対してread:org_auditが必要です。

チェックを実行する

各実行は、その日の日次の再読み取りが完了した後に開始し、遅れて届いたアクティビティが保存されているようにします。

1. 組織を一覧表示するで、リンクされた組織を一覧表示します。それぞれのuuidが得られます。
2. 組織ごとにエンドポイントを1回呼び出します。200が返されるか、エンドポイントが対応していない組織の場合は毎回の実行で404が返されます（Security postureの利用可能性を参照）。404は、その組織がこの実行では読み取られないことを意味します。200を返す組織の一覧を、それぞれ最初の200のevaluated_at（その組織に対する最初の実行）とともに保持します。
3. 除外ルールに挙げられているものを除外します。
4. その組織の残りの保存済みの表明のアクティビティをセキュリティコントロールごとにグループ化し、それぞれで created_at が最新のものを取ります。コントロールごとに1つのアクティビティが得られるか、何も得られません。
5. 残った各コントロールについて、判断表で該当する行を見つけます。一致、想定内、または要調査が得られます。
6. 「要調査」に対処するのは、その組織を読み取る次の実行で再び表示された場合のみです。行6にはただちに対処し、行10と11については代わりにプレースホルダーのルールに従います。組織を読み取らなかった実行はカウントされず、待機をやり直させることもありません。

呼び出しのペースを調整し、429は429 Too Many Requestsの説明に従って処理します。再試行後も呼び出しが失敗する組織は、この実行では読み取られていないものとします。失敗した呼び出しは変更ではありません。

フィールドを照合する

レスポンス内のエントリを保存済みのアクティビティと照合するには、次のフィールドを使用します。

比較できないものを除外する

比較する前に、次のものを除外します。

各不一致の意味を判断する

残った各コントロールは、ちょうど1つの行に該当します。

2つのソースを照合できない場合にプレースホルダーを保持する

プレースホルダーは、2つのソースのうち一方に欠けているものの代わりとなるもので、保存済みのアクティビティとは分けて保持します。行10と11については、フィードを再度読み取り、日次の再読み取りが及ぶ範囲である15日以内に何も届かない場合にのみ、プレースホルダーを保存してフラグを付けます。最初の実行では、レビューなしで直ちに保存します。

行10のプレースホルダー（コントロールとattested_atで一意に識別される）：

1. そのコントロールの最新の保存済みアクティビティから、または何も保存していない場合はattested_at（この時刻を含む）から再度読み取ります。15日間はattested_atから数えます。エントリからプレースホルダーを作成し、アクティビティがないものとしてマークします。判断表では、それをそのattested_atにおけるattestedアクティビティで、値がそのstatus（ある場合）と対応するものとして読みます。
2. 表明が表示される各実行で、そのstatusとstateを更新します。
3. created_atがそのattested_atと等しいアクティビティが届いたら、プレースホルダーをそれで置き換えます。
4. 2回連続の実行で表明が表示されない場合は、プレースホルダーを解決します。そのコントロールについて、より新しい保存済みアクティビティまたは未解決の行10の不一致でそれが説明できる場合、または両方の実行でdescriptiveが表示される場合を除き、レビュー対象としてフラグを付けます。
5. 組織を読み取らなかった実行、またはnot_evaluatedが表示される実行は、その2回の実行にカウントされず、カウントをやり直させることもありません。
6. 表明が再び表示された場合は、同じプレースホルダーを再開します。

行9、11、15のプレースホルダー（コントロールのみで一意に識別される）：

7. 行11の場合、15日間はそのstatusが表示される最初の実行から数えます。プレースホルダーが未解決である間は、そのコントロールについてそれ以上フラグを付けません。より新しいアクティビティが届いたとき、表明が表示されたとき、または2回連続の実行が別の行に該当したときに、プレースホルダーを解決します。
8. 表明がfailed_check_accepted_riskとして表示されたために行9のプレースホルダーが解決した場合は、1回、レビュー対象としてフラグを付けます。リスクが有効になっています。

具体例

次の2回の実行は、結果リファレンスのレスポンスのサンプルにある組織を読み取ります。実行1が最初の実行です。

• 実行1、directory_sync_enabled。保存済み：attested、accepted_risk、作成日時2026-10-20T15:04:00.220114Z。レスポンス：failed_check_accepted_risk、in_force、同じattested_at。行1：一致。
• 実行1、allowed_invite_domains。保存済み：なし。レスポンス：descriptive、attestationはnull。ルールS4：除外。
• 実行1、oauth_conditional_access。保存済み：なし。レスポンス：stateがreview_dueのattestation。行10：要調査。初回の実行では、レビューせずに直ちにプレースホルダーを保存します。
• 実行2、oauth_conditional_access。プレースホルダー：実行1のもの。レスポンス：同じ。行5：想定内。review_dueに対して1回対処します。

チェックで見つけられないもの

レスポンスが自動コントロールについて省略する表明に対しては、欠落しているアクティビティを日次のチェックで見つけることはできません。レスポンスには、そのような表明の兆候がまったく表示されないか、statusのfailedのみが表示されます。これは、自動チェックが与えるステータスと同じように見えます。

組織が応答しなくなった場合

200を返した後、何回か連続する実行で404を返す組織には、1回、人による対応が必要です。Security postureページにアクセスできるユーザーに、その組織に対してページがオフにされたかどうかを確認してください（Security postureの利用可能性を参照）。ページがオフにされていなかった場合は、Anthropicの担当者に連絡してください。組織が削除されたか、またはその組織に対するアクセス、Security posture、またはエンドポイントが終了した可能性があります。原因にかかわらず、その組織のプレースホルダーと未解決の不一致をレビューなしで解決し、その組織の呼び出しを続け、その組織から200が返された場合はそれらを再開します。