Prisma Cloudによる「Dismiss」ステータスが設定されたAlertの取り扱い

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 
告知
重要なadvisoryがございます。Customer Advisoryエリアにサインインし、advisoryに添付の日本語PDFファイルをご確認ください。
L3 Networker
100%が役に立ったと言っています (1/1)
「Dismiss」ステータスが設定されたAlertの取り扱いの概要:
​Prisma Cloud上でAlertが「Dismiss」ステータスへの変更が行われた場合、このステータス変更処理実施以降は、
当該Alertに対する再スキャンは一切行われません。
これは、Default Policyを構成するRQLに記載されているAPI名が変更された場合も同様となります。
よって、一度「Dismiss」ステータスに変更されたAlertはPrisma Cloudによる何らかの処理によってそのステータスが、
「Resolved」や「Open」に変更されることはございません。
 
 

​​ 現状の仕様に至るまでの経緯​:

上述の製品仕様は、Alerts 1.0、Alerts 2.0において共通する挙動となります。
​しかしながら、以下の経緯より、Alerts 1.0からAlerts 2.0へ移行するまでのタイミングで一時的に上述の製品仕様とは
異なる挙動が適用されていたことが判明致しました。
 
これは「あるAlertを検知したPolicyを構成するRQLに記載されているAPI名が変更されたにもかかわらず、当該Alertが
解決しない(Resolvedステータスにならない)」という事象がいくつか報告されたことを受け、その対応策として、
API名変更があった場合は、Alertのステータスが何であるかにかかわらず、再スキャンを実施するよう製品の挙動を
変更したためです。
Config Sanner​は​同一のAPI名から取得する属性群​を比較し、異同を確認する​という挙動が仕様通りとなりますが、
仮にAPI名そのものが変更されてしまった場合、​然るべきスキャンが実施されないという状況を考慮し
製品の挙動を変更するに至っております。

​しかしながら、その後のAlerts 2.0に向けたAlert機能の課題の棚卸と根本解決、効率的なAlert処理メカニズムの
実装を検討する中で​、「API名の変更に伴い、Alertのステータスにかかわらず全てのAlertに対する再スキャンを実施する」処理は
スキャン実施時の過負荷状態を引き起こすこと、「API名変更に伴う再スキャンの要望」が過少であることが
判明したため、以下の仕様を最終形として実装するに至りました。
 
・「API名変更に伴う再スキャン」が必要となる状況を回避するために、ポリシーを構成するRQLに記載されているAPI名や
Cloudタイプは変更不可とする
「Dismiss」ステータスへの変更が行われたAlertはスキャン対象から除外する
 
​現状の仕様とは異なる挙動が実装されていた期間は「20.7.1 ~ 20.11.2」が適用されていた​5か月間となります。
この間に「Dismiss」ステータスが設定されたAlertの取り扱いに関する挙動をご確認されたお客様におかれましては
製品仕様が不用意に変更されたという印象を与え、混乱を招くこととなりましたこと、大変申し訳ございません。
 
現在のバージョンにて実装されている「Dismimss」ステータスが設定されたAlertの取り扱い方法が本来の仕様に基づいた
挙動であるとご理解下さい。
この記事を評価:
  • 1964 閲覧回数
  • 0 コメント
  • 0 賞賛
Register or Sign-in
寄稿者
ラベル
記事ダッシュボード
バージョン履歴
最終更新日:
‎12-20-2021 08:49 PM
更新者: