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

[ashigeta]

「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の取り扱い方法が本来の仕様に基づいた

挙動であるとご理解下さい。