Orca Security の Auto Remediation (自動修復機能) について

フォージビジョン Orca Security のサービスサイトがオープンしました。

こんにちは、Orca Security 担当の尾谷です。
今日は、Orca Security で利用できる Auto Remediation (自動修復機能) についてご紹介したいと思います。

ご利用方法

Auto Remediation の機能を利用するには、アカウント接続時に実行する AWS Cloud Formation スタックに加えて、修復アクション用の Lambda 関数を含む CloudFormation スタックを実行する必要があります。

以下の画像のように、Auto Remediation (自動修復機能) にて実行された処理はアラートタイムラインに記録が残ります。

自動修復プロセス

自動修復プロセスの流れは次のとおりです。

Orca Security プラットフォームから修復指示を対象アカウントの AWS SQS キューに送信
対象アカウントの Lambda 関数が SQS によってトリガーされる
Lambda 関数が適切なアクションを呼び出してアラートを修復

なお、この Lambda 関数にアタッチされる IAM ロールには、最小特権の原則に従って自動修復アクションのみを実行するポリシーのみが含まれます。

アカウント接続時に自動修復を有効にする

アカウント接続時に有効 / 無効が選択できます。利用開始後も変更できます。
アカウント接続方法はこちらのブログ記事にてご紹介しております。

Orca Security コンソールから、Settings -> Accounts と進みます。
右側にある [Connect Account] ボタンをクリックして、

Auto remediation のチェックボックスにチェックを入れます。
チェックを入れると、手順 5 が追加されます。

手順 5 では、CloudFormation テンプレートが提供され、スタックを実行すると SQS キューや、Lambda 関数が作成されます。

Amazon SQS のコンソールを開くと、OrcaRemediationQueue が追加されていました。

SQS の URL をテキストボックスに入力して、Connect Account ボタンをクリックすると、連携完了です。

今回接続した検証環境は、Orca には接続できましたが Remediation はエラーになってしまいました。

アカウント接続後に自動修復を有効にする

AWS アカウントを Orca Security に接続した後でも、Auto Remediation は有効にできます。
Orca Security コンソールにアクセスし、Settings から Account にある Cloud Accounts を開きます。
Auto Remediation が有効になっていないアカウントは Features カラムのアイコンがグレーアウトしています。
グレーアウトしているアイコンをクリックすると、

Auto Remediation を設定する画面になるので、ARN を登録して、[Enable Auto Remediatiion] ボタンをクリックします。

今回、アカウント接続時にエラーになりましたが、上記手順にて再実施したところ有効化できました。

Auto Remediation の実行方法

Auto Remediation を実行できる対象には以下のようにアイコンがつきます。
この Auto Remediation のアイコンをクリックすると、詳細画面が右側からスライドして表示されます。

以下は、AdministratorAccess をアタッチしたスイッチロールに対して「権限が強すぎる。」とアラート検知していたものです。

手動による修復

対象のロールは、以下のように AdministratorAccess がアタッチされています。
スイッチロールとはいえ「最小権限の原則」には則しておりません。

まずは手動修正から確認してみます。
推奨されるポリシーには、かなりきめ細やかな設定が記述されていました。
一見複雑に見えますが、ポリシーが明確に指定されているため、セキュリティのスペシャリストでないオペレーターレベルのエンジニアでも対応ができます。

自動修復

次は、自動修復を確認します。[Choose auto remediation] ボタンをクリックすると、IAM ロールを削除するか、IAM に Deny-All の管理ポリシーをアタッチするといった、二択になりました。かなり乱暴な設定に見えますが、緊急時に AWS アカウントにサインインして作業を行うことなく、数クリックでブロックできるのはかなり安心できる機能と言えます。

ここでは、Deny-All の管理ポリシーをアタッチする方 (Attach Deny-All managed policy to IAM identity - MITIGATION ONLY) を実行してみることにしました。チェックボックスにチェックを入れて、[Remediate Now] ボタンをクリックしました。

直後に、スイッチロールしていた IAM ユーザーのコンソールをリロードすると急にアクセスができなくなりました。

ReadOnly アカウントにスイッチバックすると、AWSDenyAll ポリシーがアタッチされていました。

自動修復の状態では全くロールが使えない状態になったため、手動の手順に従って、ポリシーを設定し直しました。

Lambda の実行状況を確認

まずは、Amazon Simple Queue Service (SQS) の動きを確認しました。
21:22 に SQS にメッセージが送信されていました。

CloudWatch Logs にて Lambda の実行結果を確認すると、Python 3.9 にて実行されたこと、Deny All ポリシーを対象のロールにアタッチしたことなどが分かりました。
Lambda の実行ログを確認すると、どのアラートをトリガーに実行されたかが一目標然であることが分かりました。