Ctrlk
Changelog NotificationsAPIAikido login
For the complete documentation index, see llms.txt. This page is also available as Markdown.

社内アプリケーション向けAikido Broker

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

ブローカーはお使いのインフラ内で動作し、Aikido のリクエストを許可した内部 URL に転送します。Docker コンテナとして、または Helm チャートを使って Kubernetes 上にデプロイできます。

ブローカーを使うタイミング

会社ネットワーク内にのみ存在するアプリケーションやサービスに対する Aikido のあらゆるスキャンでブローカーを使用します。例えば次のようなものです:

  • オンプレミスの GitLab やその他のローカルコードプラットフォームでのコードスキャン

  • プライベートまたはオンプレミスのコンテナレジストリでのコンテナスキャン

  • 社内アプリケーションに対する AI ペネトレーテスト

  • 社内ドメインまたはサービスに対するフロントエンドおよび API テストスキャン

要件

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

  • Docker (20.10 以降) に設定し、 Docker Compose (1.29 以降) インストール済み

    • 必要に応じて Kubernetes 1.19 以降

  • Aikido にスキャンさせたいアプリケーションへのネットワークアクセス

  • へのアウトバウンド HTTPS アクセス *.aikidobroker.com

  • 小さなコンテナを実行するのに十分な CPU（1 コア）とメモリ（1 GB）

インストール

1

ブローカーのクライアントトークンを生成して設定する

へ移動 Broker Clients ページ そして新しいブローカークライアントシークレットを作成します。次のステップのために Client Secret を保存してください。

このページにアクセスできない場合は、Aikido ダッシュボードのサポートにお問い合わせください

2

リソース（内部 URL）を追加

Aikido がブローカー経由でアクセスを許可される内部 URL を定義します。

これは Aikido にスキャンさせたいアプリケーションや API です。例:

  • https://api.internal.corp.local

  • http://service-a.internal:8080

  • https://10.0.5.20

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

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

3

ブローカーを起動する

Aikido にアクセスさせたい内部アプリケーションにアクセスできるマシン上で、ブローカーサービスを起動します。必ず次を置き換えてください CLIENT_SECRET の値をクライアントページで生成したものに置き換えてください。

ブローカーが期待どおりに動作しているかは次で確認できます: docker logs aikido-broker

Windows と Mac OS では、次を使用してください: host.docker.internal の代わりに localhost または 127.0.0.1 ローカルサービスに接続します。

Aikido は次を提供しています: ブローカーをデプロイするための Helm チャート Kubernetes 環境内で。

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

ブローカーが動作しているかは次で確認できます: kubectl logs -n aikido -l app.kubernetes.io/name=broker-client

4

ブローカーが安定するまで待機してください

Aikido に接続して登録されるまで約 30 秒待ってください。

起動して接続されると、Aikido は設定した内部リソースにアクセスできるようになります。

設定

ブローカーが内部サービスに到達する方法やホスト名の解決方法を制御できます。

ALLOWED_INTERNAL_SUBNETS

ブローカーが呼び出しを許可されている CIDR 範囲の一覧です。

これを使って:

  • ブローカーを特定の内部ネットワークに限定する

  • 関係のないインフラへの意図しないアクセスを防ぐ

例：

DNS_SERVERS

ブローカーが内部ホスト名を解決するために使用する DNS サーバーの任意のリストです。

次の場合に使用します:

  • 内部 DNS ゾーンがある場合（例: *.corp.local）

  • 社内サービスがパブリック DNS で解決できない場合

例：

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

社内サービスがプライベート CA によって署名された証明書を使用している場合、その CA を指定するとブローカーが TLS を正しく検証できます。

一般的な使用例:

  • 自己署名証明書を使う社内サービス

  • サービス間暗号化のための社内 PKI

設定方法はデプロイ環境によりますが、大まかには次のようになります:

  • カスタム CA ファイルをブローカーコンテナにマウントする

  • 提供されている環境変数または設定オプションを使って、その CA ファイルをブローカーに指定する

カスタム証明書を追加する場合、ブローカーはコンテナ内でそれらを読み取れる必要があります。追加の -v フラグで証明書フォルダをコンテナにマウントし、次の NODE_EXTRA_CA_CERTS 変数で証明書ファイルをブローカーに指定します。短い例:

MTLS_PEM_PATH と MTLS_CA_PATH

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

カスタム証明書を追加する場合、ブローカーはコンテナ内でそれらを読み取れる必要があります。追加の -v フラグで証明書フォルダをコンテナにマウントし、次の MTLS_PEM_PATH に設定し、 MTLS_CA_PATH 変数です。短い例:

プロキシ

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

次のような場合に便利です:

  • ネットワークの外向きトラフィックが HTTP または HTTPS プロキシを経由しなければならない

  • 社内セグメントが中央プロキシ経由でのみ到達可能

ブローカーのプロキシ設定または環境変数でプロキシ URL を設定します: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY

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

NODE_TLS_REJECT_UNAUTHORIZED

自己署名 TLS 証明書が原因でブローカーに問題が続く場合は、'NODE_TLS_REJECT_UNAUTHORIZED' 環境変数に 0 を指定して TLS 検証を無効にするようブローカーに指示できます:

FORCE_WEBSOCKET と FORCE_POLLING

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

Aikido で Broker リソースを使う方法

ブローカーをインストールし、内部 URL をリソースとして追加すると、ブローカーは各リソースごとに一意の Aikido URL を生成します。これらの URL は、Aikido がブローカー経由で社内サービスに到達するための安全な入口として機能します。

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

重要なのは次の理由です:

  • Aikido は社内ネットワークに直接到達できない

  • ブローカーは Aikido URL を社内サービスにマッピングします

  • 内部 URL を直接使用しても機能しません

例

Domains and API スキャン（フロントエンドスキャン）を設定する際は、内部アドレスの代わりに Broker URL を使用してください。

例:

トラブルシューティング

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

まずこのコマンドを実行してください。ブローカー設定に対して簡単なヘルスチェック（DNS、接続性、その他の一般的な失敗箇所）を行い、通常は根本原因をすぐに特定できます。

ログを確認

Docker ログで警告メッセージとエラーを確認してください:

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

キャッシュされたクライアント ID が組織と一致しなくなりました。 CLIENT_SECRET 次を削除してください: config/client_id ファイルを削除して再試行してください。

ブローカーをアンインストールする

まずスキャンから Broker URL を削除してください。Broker URL を参照したままのスキャンは、ブローカーがなくなると失敗します。

次にブローカーを停止して削除します:

証明書や設定フォルダをコンテナにマウントしていた場合、それらのファイルはホスト上に残ります。不要であれば手動で削除してください。

名前空間がブローカー専用に作成された場合は、それも削除できます:

最後に、次へ移動して Broker Clients ページ クライアントを削除してください。これにより client secret が失効し、そのリソースと Broker URL が削除されます。

最終更新

役に立ちましたか？