Aikido Brokerを使った内部アプリケーションのスキャン

Aikido Brokerを使用して、インターネットから到達できない社内ネットワーク上にあるアプリケーションをスキャン・監視します。

brokerはお使いのインフラ内で稼働し、Aikidoからのリクエストを許可された内部URLへ転送します。

Brokerを使用するタイミング

社内ネットワーク内にのみ存在するアプリケーションやサービスに対するAikidoのスキャンでは、以下を含めbrokerを使用してください。

オンプレミスのGitLabやその他のローカルコードプラットフォームでのコードスキャン
プライベートまたはオンプレミスのコンテナレジストリでのコンテナスキャン
内部アプリケーションに対するAIペネトレーションテスト
内部ドメインやサービスに対するフロントエンドおよびAPIテストスキャン

要件

Aikido Brokerを実行するには、以下が必要です。

Docker (20.10+)およびDocker compose (1.29+)がインストールされていること
- オプションでKubernetes 1.19+
Aikidoにスキャンさせたいアプリケーションへのネットワークアクセス
*.aikidobroker.comへのアウトバウンドHTTPSアクセス
小規模なコンテナを実行するための十分なCPU（1コア）とメモリ（1GB）

インストール

1. brokerクライアントトークンを生成して設定する

Broker Clientsページにアクセスし、新しいbrokerクライアントシークレットを作成します。次のステップのためにClient Secretを保存してください。

2. リソース（内部URL）を追加する

Aikidoがbrokerを通じてアクセスできる内部URLを定義します。

これらは、AikidoにスキャンさせたいアプリケーションやAPIであり、例えば以下のようなものです。

Aikido UIでこれらのリソースを管理するには、既存のbrokerを一覧から選択するか、新しいbrokerを作成します。

リソースを保存すると、各リソースに対して一意のBroker URLが生成されます。Aikido内では、元のURLの代わりにこのBroker URLを使用してください。

3. brokerを起動する

Aikidoにアクセスさせたい内部アプリケーションへのアクセス権を持つマシン上で、brokerサービスを起動します。CLIENT_SECRETの値は、clientsページで生成したものに置き換えてください。

Docker

docker run -d \
  --name aikido-broker \
  --restart=on-failure:3 \
  --network host \
  -e CLIENT_SECRET="AIK_BROKER_XXX_YYY_ZZZZ" \
  -e ALLOWED_INTERNAL_SUBNETS="192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,127.0.0.0/8" \
  aikidosecurity/broker-client:latest

Brokerが想定通りに動作しているかどうかは、docker logs aikido-brokerで確認できます。

Kubernetes

Aikidoは、Kubernetes環境内にBrokerをデプロイするためのHelmチャートを提供しています。

helm repo add aikido https://aikidosec.github.io/helm-charts
helm repo update
helm install broker-client aikido/broker-client \
  --set config.clientSecret="AIK_BROKER_XXX_YYY_ZZZZ" \
  --namespace aikido \
  --create-namespace

values.yamlファイルを使用して追加パラメータを設定し、helm install broker-client aikido/broker-client -f values.yamlでコマンドを実行できます。

Brokerが実行中かどうかは、kubectl logs -n aikido -l app.kubernetes.io/name=broker-clientで確認できます。

4. brokerが安定するまで待つ

Aikidoへの接続と登録には約30秒かかります。

起動して接続が完了すると、Aikidoは設定した内部リソースへのアクセスを開始できます。

設定

brokerがお使いの内部サービスにどのようにアクセスし、ホスト名をどのように解決するかを制御できます。

ALLOWED_INTERNAL_SUBNETS

brokerが呼び出しを許可されるCIDR範囲のリストです。

以下の目的で使用します。

brokerを特定の内部ネットワークに限定する
関連のないインフラへの意図しないアクセスを防止する

例：

ALLOWED_INTERNAL_SUBNETS=10.0.0.0/8,192.168.1.0/24

DNS_SERVERS

brokerが内部ホスト名の解決に使用すべきDNSサーバーのオプションのリストです。

以下の場合に使用します。

内部DNSゾーン（例：*.corp.local）がある場合
内部サービスがパブリックDNSでは解決できない場合

例：

DNS_SERVERS=10.0.0.10,10.0.0.11

カスタムCA（内部TLS）のためのNODE_EXTRA_CA_CERTS

内部サービスがプライベートCAによって署名された証明書を使用している場合、そのCAを提供することでbrokerがTLSを正しく検証できるようにします。

典型的なユースケース：

自己署名証明書を使用する内部サービス
サービス間暗号化のための内部PKI

設定方法はデプロイ環境によって異なりますが、大まかには以下を行います。

カスタムCAファイルをbrokerコンテナにマウントする
提供された環境変数または設定オプションを使ってbrokerにそのCAファイルを指定する

カスタム証明書を追加する場合、brokerはコンテナ内でそれを読み取れる必要があります。証明書フォルダを追加の-vフラグでコンテナにマウントし、NODE_EXTRA_CA_CERTS変数でbrokerに証明書ファイルを指定します。簡単な例を以下に示します。

docker run -d \
  --name aikido-broker \
  --restart=on-failure:3 \
  --network host \
  -v /path/to/corporate-ca.crt:/certs/corporate-ca.crt:ro \
  -e CLIENT_SECRET="{secret}" \
  -e ALLOWED_INTERNAL_SUBNETS="192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,127.0.0.0/8" \
  -e NODE_EXTRA_CA_CERTS=/certs/corporate-ca.crt \
  aikidosecurity/broker-client:latest

MTLS_PEM_PATHとMTLS_CA_PATH

内部サービスがmTLS証明書を使用している場合、この2つの設定を使用できます。mTLS証明書が自己署名でない場合、CAパスは不要です。

カスタム証明書を追加する場合、brokerはコンテナ内でそれを読み取れる必要があります。証明書フォルダを追加の-vフラグでコンテナにマウントし、MTLS_PEM_PATHとMTLS_CA_PATH変数でbrokerに証明書ファイルを指定します。簡単な例を以下に示します。

docker run -d \
  --name aikido-broker \
  --restart=on-failure:3 \
  --network host \
  -v /path/to/corporate-mTLS.pem:/certs/corporate-mTLS.pem:ro \
  -v /path/to/corporate-mTLS-ca.crt:/certs/corporate-mTLS-ca.crt:ro \
  -e CLIENT_SECRET="{secret}" \
  -e ALLOWED_INTERNAL_SUBNETS="192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,127.0.0.0/8" \
  -e MTLS_PEM_PATH=/certs/corporate-mTLS.pem \
  -e MTLS_CA_PATH=/certs/corporate-mTLS-ca.crt \
  aikidosecurity/broker-client:latest

プロキシ

内部ネットワークで特定のホストやインターネットに到達するためにプロキシが必要な場合は、そのプロキシを使用するようbrokerを設定してください。

これは以下のような場合に便利です。

ネットワーク内のアウトバウンドトラフィックがHTTPまたはHTTPSプロキシを経由する必要がある場合
内部セグメントが中央プロキシ経由でのみ到達可能な場合

brokerのプロキシ設定または環境変数を通じてプロキシURLを設定します：HTTP_PROXY, HTTPS_PROXY, ALL_PROXY

また、NO_PROXY環境変数（-e NO_PROXY=noproxy.dev,my-domain.internal）を設定することで、特定のホストへのリクエストがプロキシを経由しないようにクライアントを設定することもできます。値には、プロキシをバイパスするホストのコンマ区切りリストを指定します。

NODE_TLS_REJECT_UNAUTHORIZED

自己署名TLS証明書が原因でbrokerが問題を起こし続ける場合、’NODE_TLS_REJECT_UNAUTHORIZED’環境変数に値0を渡すことで、brokerにTLS検証を無効にするよう指示できます。

docker run -d \
  --name aikido-broker \
  --restart=on-failure:3 \
  --network host \
  -e CLIENT_SECRET="{secret}" \
  -e ALLOWED_INTERNAL_SUBNETS="192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,127.0.0.0/8" \
  -e NODE_TLS_REJECT_UNAUTHORIZED=0 \
  aikidosecurity/broker-client:latest

FORCE_WEBSOCKETとFORCE_POLLING

brokerはデフォルトでwssトラフィックで動作し、それが失敗した場合はロングポーリングにフォールバックします。ネットワーク要件に応じて、これらの環境変数を使用してbrokerをどちらかに固定できます。

-e FORCE_WEBSOCKET=1

-e FORCE_POLLING=1

AikidoでBrokerリソースを使用する方法

brokerをインストールして内部URLをリソースとして追加すると、brokerは各リソースに対して一意のAikido URLを生成します。これらのURLは、brokerを通じてAikidoが内部サービスに到達するためのセキュアなエントリポイントとして機能します。

これらのAikido Broker URLを、すべてのAikidoスキャンで使用してください。

これが重要な理由は以下の通りです。

Aikidoは社内ネットワークに直接到達できません
brokerはAikido URLをお使いの内部サービスにマッピングします
内部URLを直接使用しても機能しません

例

ドメインおよびAPIスキャン（フロントエンドスキャン）を設定する際は、内部アドレスの代わりにBroker URLを使用します。

例えば：

http://my-internal-app.test:8000は使用しないでください
生成されたbroker URL（例：https://4948_c562ddc641.aikidobroker.com）を使用してください

トラブルシューティング

トラブルシューティングコマンドを実行する

まず最初にこのコマンドを実行してください。broker設定（DNS、接続性、その他一般的な障害ポイント）に対する簡易ヘルスチェックを行い、通常は根本原因をすぐに明らかにします。

Docker

docker exec -it aikido-broker node /app/diagnostics.cjs

Kubernetes

kubectl exec <pod> -c broker-client -- node /app/diagnostics.cjs

ログを確認する

Dockerログで警告メッセージやエラーを確認します。

Docker

docker logs aikido-broker

Kubernetes

kubectl logs -n aikido -l app.kubernetes.io/name=broker-client

エラー：他のクライアントのリソースにアクセスできません

キャッシュされたclient idがCLIENT_SECRETの組織と一致しなくなっています。config/client_idファイルを削除して再試行してください。