自動一時停止とハイアラートラグ設定 🔗
自動一時停止とは? 🔗
自動一時停止は、オンコールインスタンスが合計5,000件以上のアクティブインシデントに達したときに発生するセキュリティイベントです(トリガー済みまたは確認済みの状態にあるインシデントとして定義されます)。自動一時停止がトリガーされると、すべてのアラート処理が停止され、インスタンスに着信するすべてのアラートをキューに入れ始めます。このバックログにより、アラート遅延がすぐに発生する可能性があります。インスタンスが5,000アクティブインシデントのしきい値を超え、自動一時停止がトリガーされた場合、アカウントを再有効化するためにオンコールサポートとのコミュニケーションが必要となります。
ハイアラートラグとは? 🔗
ハイアラートラグは、監視ツールからOn-Callインスタンスにアラートが送信される速度が、当社のシステムで処理できる速度よりも速い場合に発生します。これは、組織が一時停止していなくても発生する可能性があり、大量のINFOまたはRESOLVEDアラートのように、インシデントを作成しないアラートによって引き起こされる可能性があります。当社のアラート処理の限界は、1分あたり150アラート(1秒あたり2アラート)です。
自動一時停止とアラートラグの原因は? 🔗
自動一時停止もアラートラグも、Splunk On-Callの上流にある監視ツールからアラートが送信されるループが繰り返されることで発生する症状であることが多いため、問題の潜在的な原因としてそのツールを調査していただくようお願いします。自動一時停止は、アラートストームとは関係なく、解決されずにアラートがたまりすぎたためにトリガーされることもあります。インシデント管理のベストプラクティスに従うことで、このような状態に陥ることを避けることができます。
ベストプラクティス: 🔗
ハイジーン 🔗
インシデントに対処し、できるだけ早く解決する技術を実践します。
タイムラインの インシデントペイン で、アクティブな(トリガーされた、またはアクノレッジされた)インシデントを定期的にチェックすることで、個々のインシデントにアクションを起こしたり、一度に解決/確認したりすることができます。
設定 🔗
古いインシデントを手動で管理することが組織にとって現実的でない場合は、インスタンスで 自動解決 機能を有効にすると便利です。これにより、アクティブなインシデントを指定した期間後に解決するように設定できます。
必ずしも誰かをページングする必要のないアラートが多数寄せられる場合、アラートルールエンジン を使用して、それらをInfoアラートに変換することができます。このアラートは、追跡のためにタイムラインに表示されますが、インシデントをトリガーすることはありません。
設定 🔗
インシデントを発生させるメッセージに加えて、監視ツールからシステムのRESOLVEメッセージを送信する習慣を身につけましょう。これらのアラートが同等の entity_id を持っていることを確認することで、これらのアラートをリンクできます。
単一の関連イベントに対するアラートが関連付けられるようにツールを設定することは、追跡に役立つだけでなく、アラートストームの中で自動一時停止から保護する上でも非常に役立ちます。これは、アラートアグリゲーション <spoc-alert-aggregation> を活用して、組織内のアクティブなインシデントの数を減らします。これは、entity_id フィールドを使用して、関連するアラートを、メッセージごとに新しいものを作成するのではなく、最初のトリガーされたインシデントの下にロールアップできるようにします。
モニタリングツールで entity_id を設定することができない場合は、アラートルールエンジン を活用して、集約したいインシデントに固有の別の関連条件にマッチングさせることで、このフィールドを手動で設定することもできます。詳細については、ルールエンジンのマッチング条件 を参照してください。
アラート集約は自動一時停止を防ぐことはできますが、アラートラグを防ぐことはできません。単一のインシデントであっても、その下に多くのアラートが集約されている場合、この状態を引き起こす可能性があります。可能であれば、監視ツールを監査して、アラートを毎分150メッセージ未満に制限してください。
自動一時停止を解除する方法 🔗
組織が自動一時停止の状態になるとすぐに、Splunk On-Callサポートチームからそのイベントを知らせるメールが届きます。この連絡を受けた場合は、受信者が各インスタンスのグローバル管理者であるか、インシデントが多く発生するチームのチーム管理者であるか、現在オンコール状態であることが考えられます。
最初のステップは、アクティブなインシデントが多い原因を特定し、それを解決することです。その後、アクティブなインシデントのすべてまたは大部分を組織内で解決する必要があります。
アラートストームが発生しなくなり、すべてのアクティブなインシデントが解決されたことを確認できたら、アラートを再度有効にするに2つのオプションがあります:
処理待ちのアラートのキューを削除し、インスタンスの一時停止を解除することができます。これは当社の推奨ですが、アラートを見逃す結果になります。
インスタンスの一時停止を解除し、キューに入れられたアラートを処理することができます。これにより、タイムラインにアラートが表示されるようになりますが、潜在的なアラートの量が多いため、アラートの遅延が発生し、すぐに別の自動一時停止イベントが発生する可能性があります。
どのオプションが組織に適しているかを決定したら、連絡を受けたサポートエンジニアにご希望をお伝えください。適切な処置(許可を得てバックログをクリアする、許可を得てすべてのインシデントを解決する、など)を行い、アラートが再有効化されたら通知します。