Orca Security を AWS に繋いでみた – 15 分で終わるエージェントレス CNAPP の導入

こんにちは、セキュリティエンジニアの田所です。

CNAPP の Orca Security を、検証用の AWS アカウントに接続してみました。
Orca Security はエージェントレスに強みを持つ CNAPP です。
簡単にセットアップが完了することを期待して始めたところ、なんと接続作業を 約 15 分 で終えられました。
さらに、繋いだだけで資産やリスクの情報が集まり、どう対応するべきか、具体的なアクションを確認することができました。

本記事では、Orca Security の概要、AWS アカウントの接続手順と注意点、そして繋いだ後にコンソールで見える画面を紹介します。
クラウドのセキュリティを強化したいと考えている方、CNAPP を検討していて Orca Security が気になっている方の参考になれば幸いです。

1. Orca Security とは？

そもそも CNAPP とは？

CNAPP (Cloud Native Application Protection Platform) は、クラウド環境を守るためのセキュリティ機能を 1 つのプラットフォームに統合したものです。
統合される代表的な機能は次のとおりです。

• CSPM: クラウドの設定ミスを検出する
• CWPP: 仮想マシンやコンテナなどのワークロードを保護する
• CIEM: クラウドの権限 (ID とアクセス) の過剰付与を管理する
• DSPM: 機密データの所在とリスクを把握する

本記事では、このうち CSPM・CWPP・CIEM にあたる検出結果を紹介します。
DSPM にあたるデータベースのスキャンは、今回は機能をオフにして接続したため対象外です。

売りは SideScanning (エージェントレス)

Orca Security の特徴は、SideScanning と呼ばれるエージェントレスのスキャン技術です。
ワークロードの中にエージェントを入れる代わりに、クラウドの API とストレージ層の外側から情報を集めます。

スキャンは次の 3 段階で進みます。

1. コントロールプレーン: クラウドプロバイダの API で設定情報を読み取る
2. データプレーン: EBS のスナップショットを取得して Orca 側で解析し、解析後すぐに削除する
3. コンテキスト分析: 1 と 2 の情報を組み合わせて、リスクを文脈つきで評価する

Orca のドキュメントでは、エージェント型と比べたメリットとして、次のような点が挙げられています。

Requires a one-time integration with your cloud provider. You don’t need to install any agents
(クラウドプロバイダとの統合は 1 回だけで、エージェントのインストールは不要)

Builds a full model of your cloud environment without affecting cloud resources.
(クラウドのリソースに影響を与えずに、クラウド環境の全体像を把握する)

The scan is performed independently on OS, VPC, credentials, or VM run-state.
(スキャンは OS・VPC・認証情報・VM の稼働状態に依存せずに行われる)

出典: Orca Security ドキュメント「SideScanning Technology Overview」(閲覧にはサインインが必要です)

脆弱性・設定ミス・マルウェア・ラテラルムーブメント (侵入した攻撃者が、別のシステムへ横に広がっていくこと) のリスク・機密情報まで、幅広く検出できます。

今回使う SaaS モードでは、スナップショットの解析は Orca 側のスキャナアカウントで行われます。
スキャンのたびに EBS のスナップショットが一時的に作られますが、解析後に削除されます。
自分の AWS アカウントに常に残るのは、IAM ロールとポリシーだけです。

今回は、AWS アカウント 1 つを単独で接続しました。
なお、利用したプランは Premium です。
プランによっては、本記事の画面の一部が表示されない場合があります。

SideScanning の仕組みは、公開されている技術資料にまとまっています。

• SideScanning – Inside the Engine that Powers Orca Security

2. AWS と Orca Security を接続する

接続は、Orca の画面から始めて、AWS の CloudFormation でスタックを作り、Orca に戻って完了する流れです。
指示に従って設定を進めると、テンプレートの中身をレビューした時間を含めて、約 15 分で接続が完了しました。

本章のうち英語表示の画面は、過去の接続時に撮影したものです。
2026 年 10 月時点では、コンソールは日本語表示に対応しています。

2-1. アカウントセンターから接続を始める

Orca の設定からアカウントセンターを開きます。
まだ何も繋いでいない状態です。

アカウント接続から、接続するプロバイダとして AWS を選びます。

2-2. 有効にする機能を選ぶ

ウィザードの最初のステップで、有効にする機能を選びます。
管理対象データベースは、初期状態でチェックが入っています。
今回は最小構成で繋ぐため、自動修復 (一部のアラートを Orca が自動で修正する機能) と管理対象データベース (RDS や DynamoDB などのデータベースの機密データをスキャンする機能) はどちらもオフにしました。
画面にも「後でアカウントセンターで実行できます」とあるとおり、後から有効にできます。

2-3. CloudFormation でスタックを作成する

ウィザードの CloudFormation テンプレートのリンクを開くと、AWS の「スタックのクイック作成」画面に移ります。
ここでパラメータを確認して、スタックを作成します。

注意点: SecretManagerAccess は自分で false にする

ウィザードの「管理対象データベース」の設定は、CloudFormation のパラメータに反映されます。
チェックを外してからテンプレートのリンクを開くと、次のように表示されました。

DynamoDB・RDS・Redshift のスキャン用のパラメータはすべて false です。
SecretManagerAccess だけは、テンプレートのデフォルト値の true のままになっています。
true のまま作成すると、タグ Orca: SecretAccess の付いたシークレットの値を読む権限 (secretsmanager:GetSecretValue) が追加されます。
この権限は、パスワードで保護されたコンテナレジストリをスキャンするためのものです。
false にすると、そうしたレジストリの中のイメージはスキャンされません。
該当するレジストリがなければ、最小権限で繋ぐためにこの画面で false に切り替えてから作成しましょう。

出典: Orca Security ドキュメント「AWS: Enabling Scans of Password-Protected Registries」(閲覧にはサインインが必要です)

作成されるもの

作成されるのは、IAM ロール 1 つとポリシー 2 つです。
あわせて、AWS 管理ポリシーの ViewOnlyAccess がロールにアタッチされます。
以下は、2026 年 9 月時点のテンプレート (orca-cf-version 1.0.20) の内容です。

書き込み系の権限は、テンプレートを見る限り次の範囲に限られています。

• EC2 スナップショットの作成・コピー・タグ付け・共有 (削除は Orca タグの付いたスナップショットのみ)
• 暗号化されたスナップショットを扱うための KMS 操作
• EKS のアクセスエントリの作成 (Orca のロール自身の分のみ。紐付けられるアクセスポリシーは閲覧系のみ)

ロール名の末尾のサフィックスは、CloudFormation がスタック名と論理 ID をもとに自動で付けるものです。

2-4. ロール ARN を Orca に貼って接続する

スタックが CREATE_COMPLETE になったら、出力タブの OrcaRoleArn をコピーします。

Orca のウィザードに戻り、Orca ロール ARN の欄に貼り付けて接続します。
アカウントセンターに戻ると、ステータスが Online になっていました。

エージェントのインストールは一切なし。
やったことは、CloudFormation のスタックを 1 つ作っただけです。

2-5. 裏で何が起きているかを CloudTrail で追う

エージェントを入れていないのに、Orca は本当に AWS アカウントを見ているのでしょうか？
CloudTrail のイベント履歴を、ユーザー名 orca で絞り込んで確認してみました。

接続の 10 分後から、S3 の Get 系 API がずらりと並び始めました。
すべて読み取り専用の API で、コントロールプレーンのスキャンにあたります。

ちなみに接続の 30 分後に Orca のインベントリを開くと、まだ「Scanning in progress」の表示でした。
画面にはまだ何も出ていなくても、裏では CloudTrail にスキャンの活動が記録されています。

後日の日次スキャンでは、スナップショットの削除 (DeleteSnapshot) と、ECR のコンテナイメージの取得 (GetDownloadUrlForLayer / BatchGetImage) も記録されていました。
こちらはデータプレーンのスキャンの証跡です。

AWS 側のログでも、Orca の動きを確認できました。

3. Orca Security コンソールで確認できること

初回スキャンの結果が揃うまでの目安は、ドキュメントで次のように案内されています。

To obtain a complete view of your security posture, allow up to 24 hours for initial scan results.
(セキュリティ状況の全体像を把握するには、初回スキャンの結果が出るまで最大 24 時間を見込んでください)

出典: Orca Security ドキュメント「Initial Scan Times」(閲覧にはサインインが必要です)

ここからは、スキャンの結果が揃った後の画面を紹介します。

3-1. インベントリ: 資産を自動で検出

インベントリには、検証用アカウントの AWS の資産が一覧で並んでいました。
接続 30 分後の「Scanning in progress」の画面からのビフォーアフターです。
資産ごとにリスクスコア・アラート・脆弱性の件数が並び、見やすいです。

なお、画面上部の「リスクレベル別アセット」は資産の数です。
後述するアラート数とは単位が違います。

3-2. 概要ダッシュボード: アラートと SLA がひと目で分かる

概要ダッシュボードでは、リスクレベル別のアラート数、アラートの SLA、アラート上位 10 件が 1 画面にまとまっています。
アラートの SLA は、既定では重大 (Critical) が 10 日、高 (High) が 30 日、中 (Medium) が 90 日で、期限の 75% を過ぎると「リスクあり」になります。
この基準は、ウィジェットの絞り込みから変更できます。

出典: Orca Security ドキュメント「Overview Dashboard」(閲覧にはサインインが必要です)

アラート上位 10 件には、EICAR テストファイル (マルウェア検知のテスト用ファイル) の検出が入っていました。
この検証用アカウントは他のメンバーも使っており、検証のために置かれたファイルです。
EICAR テストファイル自体は無害ですが、マルウェアとしてきちんと検出されています。

3-3. アラート: 種類ごとにまとまり、修復手順まで出る

アラートの画面では、アラートが種類ごとにまとまって並びます。
インターネットに露出している資産のアラートや、重要な資産 (クラウンジュエル) のアラートも、画面上部で件数が分かります。
種類の中には、特権を持つ IAM ロールや使われていない IAM ロールといった、権限まわり (CIEM) の検出も含まれていました。

アラートを 1 件開くと、概要・スコア内訳・修復の 3 つのタブがあります。
スコア内訳では、外部への露出や想定される被害など、スコアを決めた要因が並びます。

修復のタブには、推奨の修復手順が出ます。
なぜ危ないのか、どこから直せばいいのかを、1 つの画面で追えます。

3-4. 資産の詳細: 停止中の EC2 でも中身まで見える

インベントリから EC2 インスタンスを 1 台開いてみました。
このインスタンスは停止中です。
それでも、OS のバージョンと、検出された脆弱性の件数が表示されています。

停止中のインスタンスでは、中でエージェントを動かすことはできません。
1 章で引用した「スキャンは VM の稼働状態に依存しない」を、自分の環境で確かめられた形です。
画面の下には、インターネットからこのインスタンスまでの経路もグラフで表示されます。

3-5. 脆弱性: 件数と優先度の絞り込み

脆弱性の画面では、検出された脆弱性が深刻度や資産の種類ごとに集計されます。
脆弱性ファネルでは、パッチ適用可能 → 悪用可能 → 公開アセット上、と条件を重ねて絞り込めます。
画面上部のフィルターで深刻度を重大 (Critical) に絞ってからファネルを見ると、対象はさらに少なくなります。
まずはここから手を付ける、という使い方ができそうです。

3-6. コンプライアンス: フレームワークごとのスコア

コンプライアンスの画面では、フレームワークごとの準拠状況が並びます。
今回の画面では、Orca 独自のフレームワークが 3 つ表示されていました。
全体のスコアは、コントロール別とアセット別の 2 つの見方で表示されます。

3-7. アタックパス: 攻撃経路をグラフで見る

アタックパスの画面には、検出された攻撃経路が一覧で並びます。

1 件開くと、外部ネットワーク → EC2 インスタンス → IAM ロール → S3 バケットという経路が、グラフで表示されます。
途中の EC2 インスタンスには、OS の未適用パッチがあることも示されています。
個々のアラートだけでは見えにくい「つながり」が、1 枚の絵で分かります。

3-8. アカウントセンター: 課金対象のワークロード

アカウントセンターでは、Orca の課金対象のワークロード数が表示されます。
インベントリの資産の数に対して、かなり少ない数字でした。
Orca では、Lambda は 50 関数で 1 ワークロード、S3 バケットは 10 個で 1 ワークロードのように、資産の種類ごとに換算比率が決まっているためです。

出典: Orca Security ドキュメント「Billable Workload Overview」(閲覧にはサインインが必要です)

まとめ

わずか 15 分ほどで AWS アカウントへの導入が完了しました。
エージェントは入れず、CloudFormation で IAM ロールを 1 つ作るだけです。
そして繋いだだけで、資産・リスク・コンプライアンスまでの情報が 1 つのコンソールに見やすく並びます。

次回は、これらの機能をもう少し掘り下げて検証してみようと思います。

本記事が少しでも皆様の参考になりましたら幸いです。

Orca Security の導入を検討している方は、リセールパートナーの弊社にぜひご相談ください。