こんにちは、ビデオリサーチのオジサンです。
とある案件にて外部機関による本格的な脆弱性診断を受ける前に、試しにWebアプリケーションの脆弱性診断を実施したいという要望がありました。
そこで今回はIPAでも推奨しているオープンソースのWebアプリケーションの脆弱性診断ツールとして公開されているOWASP ZAPを使用してみることにしました。
このOWASP ZAPですが、OWASP TOP10と呼ばれる重大なセキュリティの診断、自動スキャン、手動スキャンに加え、プロキシによる通信の分析まで出来ます。
実行環境についてもWindows, Linux、Mac、Dockerと複数用意されていますが、今回はDocker版OWASP ZAPを使用しました。
コンテナならGoogle CloudのCloud Runにデプロイしてみようということで、その手順をまとめてみました。
作業手順の流れ
今回はDocker版を利用しますので、下記の手順で作業を進めます。
- Dockerfileの用意
- コンテナイメージの作成
- ArtifactRegistoryへの登録
- Cloud Runにデプロイ
- おまけ:Compute Engineでも動かしてみる
1.Dockerfileの用意
公式のドキュメントにある記載の通り、Docker版を起動するだけなら2行で終わります。
以上。。。。
docker pull ghcr.io/zaproxy/zaproxy:stable docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable zap.sh -cmd -autorun /zap/wrk/zap.yaml
今回はCloud Runで起動させることを想定し、公式のDocker版owapszapをベースにDockerfileを用意します。
ZAP Desktop GUIを起動するようにしたいので下記のようにしました。
FROM ghcr.io/zaproxy/zaproxy:stable USER root ENV TZ=Asia/Tokyo RUN apt-get update && \ apt-get -y install fonts-noto-cjk USER zap EXPOSE 8080 EXPOSE 8090 CMD ["zap-webswing.sh"]
2.コンテナイメージの作成
用意したDockerfileをDockerイメージにビルドします。
docker build -t asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest .
[PROJECT_ID]
はGCPのプロジェクトIDに置き換えてください。
3.ArtifactRegistoryへの登録
最初にArtifact Registryにowaspzapの名称でリポジトリを作成しておきます。
次に作成したイメージをGCPのArtifact Registryにプッシュします。
gcloud config set project [PROJECT_ID] gcloud auth configure-docker docker push asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap-proxy
[PROJECT_ID]
はGCPのプロジェクトIDに置き換えてください。
※Container Registryは、2025年3月18日以降提供終了となりますので、Artifact Registryを利用しましょう。
4.Cloud Runにデプロイ
Cloud Runにowaspzapをデプロイするには、以下のコマンドを実行します。
gcloud run deploy owasp-zap \ --image asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest \ --platform managed \ --region asia-northeast1 \ --allow-unauthenticated \ --memory 2Gi
パラメータ解説
--image
: デプロイするコンテナイメージを指定。--platform
: Cloud Runのマネージドプラットフォームを使用。--region
: デプロイ先のリージョンを指定。--allow-unauthenticated
: 認証なしでアクセスを許可。--memory
: 割当メモリ量。
メモリは最低2GBぐらい必要なようです。1GBでは起動できませんでした。
今回はテスト的に起動を試したので、 --allow-unauthenticated
を指定して起動確認をしました。
このままだと誰でもアクセスできてしまうので、本運用する際には --no-allow-unauthenticated
を指定し、ロードバランサやCloudArmorを利用してIP制限等掛ける必要があるでしょう。
検査対象によってはvpc-connectorを用意し、VPC内の環境にアクセスできるようにすることも必要になると思います。
owaspzapのレポート等は/zap/wrkに出力されます。結果を残しておきたい場合は、CloudStorageにボリュームを作成しマウントしておくと良いでしょう。
以上でビルドからデプロイまでが完了しました。
デプロイしたCloud RunのURL https://起動したアドレス/zap/
にブラウザでアクセスするとowaspzapのWebSwing版画面が表示されるはずです。
※Dockerコンテナ内では8080ポートで起動しますが、自動的にポートマッピングされてます。
5.おまけ:ComputeEngineでも動かしてみる
owaspzapにはproxyとして利用する機能があります。こちらはデフォルトで8090ポートを使用します。
Cloud Runでは2つのポート番号を同時使用できないため、このままでは利用できません。
(リバースプロキシもコンテナ内に組み込めばなんとかなる気もしますが試してません)
proxyも使えるようにしたかったため、Compute Engineで動くようにしてみました。
せっかくなので今回用意したDockerfileを使用して起動させます。
Compute Engineの箱を用意するのは説明不要かと思いますので省略します。
※ e2-mediumでDebianを使用しました。
起動したCompute EngineにSSHでログインし、下記手順にて作業を行います。
5.1 Dockerのインストール
パッケージ情報を最新にし、 Dockerをインストールします。
sudo apt update sudo apt install -y docker.io
5.2 Dockerサービスの起動
Dockerサービスを起動し、OS再起動時も自動起動するようにします。
sudo systemctl start docker sudo systemctl enable docker
5.3 Dockerイメージのダウンロード
「3.ArtifactRegistoryへの登録」の手順まで実施済みであれば、リポジトリへのイメージ登録まで終わってますので、その前提でイメージのダウンロードを実施します。
gcloud auth configure-docker docker pull asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest
[PROJECT_ID]
はGCPのプロジェクトIDに置き換えてください。
5.4 Dockerコンテナの実行
Dockerコンテナを起動して、owaspzapを利用できるようにします。
--restart unless-stopped
を指定することで、再起動しても自動起動するようにします。
docker run -d --name owaspzap-proxy --restart unless-stopped -p 8080:8080 -p 8090:8090 asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest
[PROJECT_ID]
はGCPのプロジェクトIDに置き換えてください。
ブラウザで、 https://Compute EngineのグローバルIPアドレス:8080/zap/
にアクセスするとWebSwing版画面が表示されます。
プロキシの設定でIPアドレスにCompute EngineのグローバルIPアドレスを指定し、ポート番号は8090を指定することで、プロキシとして使用できるようになります。
まとめ
Cloud Runを使用すると、簡単にデプロイ、実行でき、インフラ管理の負担を減らせて使った分のコストだけで済むので、制約はあるものの使い勝手が良いですね。良い時代になりました。
最後のおまけで記載したように、Compute Engineを採用する場合でも、Dockerコンテナを起動するようにすることで、簡単に起動させることができました。
何よりポータブルなのでAWSやローカル環境等でも使えます。
今回はインフラの話でしたが、オジサンのメインスキルは開発なので、機会があれば開発系の記事でも書いてみたいと思います。
最後まで読んでいただきありがとうございました!