はじめまして。5月にM&Aクラウドへ入社した、峯岸です。 既に1ヶ月が経過しましたが、入社エントリを書いていきます。 まずは軽く自己紹介を。 神奈川県出身で、新卒からバックエンドエンジニアとして働き始め、現在4年目です。 趣味はゲームで、モンスターハンターのような協力プレイができるゲームが特に好き。 意外かもしれませんが、折り紙もたまにやります。小学生の頃に熱中していた名残で、今では記憶をたどりながら作ることがある程度ですが。 前職について 以前はイベント系の会社に3年ほど在籍しており、LaravelやCakePHP等のPHPフレームワークを主に用いたプロダクト開発・案件開発を行っていました。…

本記事は 2026 年 4 月 15 日に Migration & Modernization Blog で公開された AWS Transform: Comprehensive Codebase Analysis for Modernization を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 アプリケーションのモダナイゼーションは、多くの場合、困難なタスクから始まります。それは、システムの仕組みを理解するための包括的なレガシーコードベース分析です。多くのレガシーアプリケーションは長年にわたる段階的な変更を経て進化しており、ドキュメントは限られ、依存関係は密結合し、ビジネスロジックは複数のサービスやモジュールに分散しています。エンジニアリングチームにとって、この可視性の欠如は共通の課題を生み出します。モダナイゼーションを開始する前に、開発者はソースコードを確認してアプリケーションアーキテクチャ、動作パターン、隠れた依存関係を理解するための時間を費やす必要があります。この作業を行っても、サービス間の依存関係、アーキテクチャ上の制約、埋め込まれたビジネスルールなどの重要な知見は、変更がより複雑でコストがかかるプロジェクトの後半で明らかになることがよくあります。 AWS Transform の包括的コードベース分析マネージド変換は、アプリケーションの明確でエビデンスに基づいた理解を提供することで、これらの課題に対処します。これにより、数か月分の手作業を節約し、モダナイゼーションへの取り組みを加速できます。この記事では、変換の仕組み、前提条件、実行手順、実践的なシナリオを含めた結果の解釈方法、より広範なモダナイゼーションの取り組みとの関係、ベストプラクティス、トラブルシューティングガイダンスについて説明します。この記事を読み終えた頃には、ドキュメントが不十分なレガシーコードベースを構造化されたナビゲーション可能なナレッジベースに変換するための再現可能なアプローチを習得できるでしょう。 AWS Transform の包括的コードベース分析の仕組み この変換は、静的コード解析に基づいて動作します。決定論的ツール、基盤モデル（FM）、大規模言語モデル（LLM）、グラフニューラルネットワーク、自動推論を組み合わせて、アプリケーションコードベースの 4 つの重要な側面を分析します。 システム全体のコンポーネントの関係と依存関係 コードがどのように機能するかを明らかにする動作パターン 実装に埋め込まれたアーキテクチャ上の決定 ステークホルダーとのコミュニケーションのために平易な言葉で抽出されたビジネスロジック この多層的な分析により、技術チームとビジネスリーダーの両方が、実装中に問題が発生する前に十分な情報に基づいたモダナイゼーションの意思決定を行うのに役立つ構造化されたドキュメントが生成されます。 前提条件 開始する前に、以下を確認してください。 AWS Transform コマンドラインインターフェース （CLI）がインストールされていること: 詳細は スタートガイド を参照。 AWS 認証情報が設定されていること: 適切な権限で AWS CLI をセットアップし、AWS 認証情報に AWS Transform サービスを呼び出す権限があることを こちら で確認。最低限、 transform-custom: * の権限が必要。 クリーンな状態の読み取り可能なファイルを含む Git ソースコードリポジトリを準備すること: コミットされていない変更はコミットまたはスタッシュ。 推定所要時間: 30〜45 分（分析の実行時間を除く。実行時間はコードベースのサイズによって異なります） ステップバイステップガイド: 包括的コードベース分析の実行 以下の手順では、レガシーアプリケーションに対して AWS Transform の包括的コードベース分析を実行し、主要なステークホルダーと結果を共有し、インサイトに基づいて行動するまでの完全なプロセスを説明します。 ステップ 1: 環境の確認 AWS Transform が正しくインストールおよび設定されていることを確認します。 atx -version atx custom def list 上記のコマンドは、 AWS/early-access-comprehensive-codebase-analysis などの利用可能な AWS Transform マネージド変換を表示します。 注: 早期アクセス変換 (early-access-*) は機能しますが、お客様のフィードバックに基づいて頻繁に更新される可能性があります。時間が経つと、変換の名前が「AWS/comprehensive-codebase-analysis」として一覧に表示されるようになります。 図 1: AWS マネージド変換のリストで包括的コードベース分析変換が利用可能であることを確認 ステップ 2: コードベースの準備 Git リポジトリがクリーンな状態であることを確認します。 git status 図 2: 分析を実行する前に Git リポジトリがクリーンな状態であることを確認 既存のソースコードリポジトリをクローンします。 git clone <repository-url> 図 3: 包括的分析のためにレガシーコードベースリポジトリをクローン ステップ 3: ターミナルで以下のコマンドを実行 AWS Transform を使用して包括的分析を開始します。これにより、リポジトリ内のすべてのファイルと依存関係に対して深い静的解析が実行されます。 cd /path/to/your/project atx custom def exec -p /path/to/your/repository -n AWS/early-access-comprehensive-codebase-analysis -c "noop" -x -t 注: -n は変換名を指定します -c "noop" – ビルドコマンド（no operation – ビルドステップをスキップ） -x – 確認プロンプトなしでツールを自動信頼/実行 -t – インタラクティブターミナルモードを有効化 図 4: AWS Transform CLI を使用して包括的コードベース分析変換を実行 ステップ 4: 追加コンテキストの提供（オプション） よりターゲットを絞った分析を行うために、設定ファイルを使用して追加のガイダンスを提供できます。 transform-config.yaml という名前のファイルを作成します。 cat > transform-config.yaml << 'EOF' codeRepositoryPath: /Users/milola/Prince-of-Persia-Apple-II transformationName: AWS/early-access-comprehensive-codebase-analysis buildCommand: noop additionalPlanContext: | Focus analysis on the following areas: - Document the overall architecture and code structure - Identify deprecated or outdated coding patterns - Highlight areas that may benefit from modernization - Analyze dependencies and their relationships EOF カスタム設定ファイルを実行します。 atx custom def exec -g file://transform-config.yaml -x -t 図 5: YAML 設定ファイルを使用して追加コンテキスト付きで分析を実行 ステップ 5: 分析のモニタリング 処理が進むにつれて、階層的なドキュメント構造にまとめられた分析結果、優先度付けされた技術的負債のインサイト、簡単にナビゲートできる相互参照されたナレッジベースが提供されます。コードベースのサイズと複雑さに応じて、完全なプロセスには通常 45 分から 2 時間以上かかります。 ステップ 6: 結果の確認 分析が完了すると、4 つの領域にわたって整理された包括的なドキュメントセットが表示されます。 技術的負債レポート: 古くなったコンポーネントの優先度付きビュー、重大度別にランク付けされたセキュリティの問題、長期的な影響について評価されたメンテナンスの懸念事項。 アーキテクチャドキュメント: コンポーネントの依存関係グラフ、サービスの相互作用パターン、データフロー図を含むシステム全体の概要。 ビジネスロジックの抽出: 複雑なプロセスのわかりやすい言葉での説明。主要なビジネスルール、バリデーションロジック、外部統合ポイントを浮き彫りにします。 コード分析: コードベースのファイルごとの内訳。複雑度メトリクス、コード品質の指標、具体的なリファクタリングの機会を提示します。 以下は、プロジェクト概要、技術的負債レポート、コード分析出力、システムアーキテクチャ概要のスクリーンショットです。 プロジェクト概要: 図 6: ビジネスコンテキストと技術的成果を含む、包括的コードベース分析によって生成されたプロジェクト概要ドキュメント 技術的負債レポート: 図 7: プラットフォームの陳腐化やハードウェア依存関係を含む、重大度別に優先度付けされた重要な問題を強調する技術的負債レポート コード分析: 図 8: 複雑度、保守性の指標、品質評価を示すコード分析メトリクス システムアーキテクチャ概要: 図 9: モジュール性と結合度の具体的な評価を含む、システムの強みと弱みを示すアーキテクチャドキュメント ステップ 7: ナレッジベースのナビゲーション 生成されたドキュメントは、ハイレベルなレビューと詳細な調査の両方をサポートするように構造化されています。 ルートレベルでは、エグゼクティブサマリーが最も重要な技術的負債の分析結果とともに表示され、即座に注意を要するインサイトが明らかになります。さらに掘り下げると、ドメインレベルでは関連するコンポーネントが論理的なクラスターにグループ化され、コンポーネントレベルでは個々のモジュールの詳細な分析が提供されます。 ドキュメント全体を通じて、相互参照が関連するコンポーネントと依存関係を接続し、チームがコンテキストを失うことなくシステム全体の関係を追跡しやすくなります。 トップから始めて、モダナイゼーションの優先事項に最も関連する領域を分析してください。 ステップ 8: エクスポートと共有 各グループが受け取る内容を、それぞれの責任と意思決定のニーズに基づいてカスタマイズします。このターゲットを絞ったアプローチにより、各チームはモダナイゼーションの取り組みにおける自分たちの役割に最も関連するインサイトに基づいて即座に行動できます。 まず、エンジニアリングチームに技術的負債レポートを提示してください。これにより、モダナイゼーション中に遭遇するリファクタリングの優先順位とアーキテクチャ上の制約が把握できます。 アーキテクチャチームは、ターゲット状態の計画と慎重な検討が必要な統合ポイントの特定に、システム全体のドキュメントが非常に有用であると感じるでしょう。 ビジネスステークホルダーは、わかりやすい言葉でのビジネスロジック抽出から大きな恩恵を受けます。これにより、変換中に重要なワークフローとルールが保持されていることを検証できます。 セキュリティチームも、依存関係の分析とアーキテクチャのインサイトを確認して、モダナイゼーションプロセスの早い段階でセキュリティに関する考慮事項を特定できます。 ステップ 9: インサイトに基づいた行動 出力は、それに基づいて何を行うかによってのみ価値が決まります。短期的には、関連するセキュリティの問題への対処、優先度の高い技術的負債の正式なドキュメント化、今後のスプリント計画への分析結果の組み込みに注力してください。戦略的には、アーキテクチャのインサイトがモノリシックシステムの分解の決定に情報を提供し、依存関係の分析に基づいてモダナイゼーションの各フェーズの実施順序を決定します。技術的負債データは、測定可能なリスクと影響に基づいた説得力のあるビジネスケースを構築するための基盤を提供します。 実践的なシナリオ 数十年の歴史を持ち、ドキュメントが最小限で、理解できる開発者が限られているモノリシックアプリケーションを引き継いだとします。そして、ビジネスステークホルダーは数か月ではなく数週間以内にモダナイゼーションのタイムラインを必要としています。包括的コードベース分析は、そうでなければ広範な手作業を必要とするディスカバリーフェーズを加速し、数週間ではなく数時間で実行可能な結果を提供します。コンポーネントの相互作用を示す完全な依存関係グラフを生成し、リスクと影響で優先度付けされた技術的負債のホットスポットを特定し、技術とビジネスの理解を橋渡しするビジネスロジックを抽出し、分解戦略に情報を提供するアーキテクチャのインサイトを提供します。この基盤により、特定のコンポーネントをリファクタリングするか、リプラットフォームするか、置き換えるかについて十分な情報に基づいた意思決定が可能になり、推測ではなくエビデンスに裏付けられた現実的なモダナイゼーションタイムラインをビジネスステークホルダーに提供できます。 より広範なモダナイゼーションの取り組みとの関係 包括的コードベース分析は、単独ではなく、より広範なモダナイゼーション機能と連携して動作するように設計されています。生成されるインサイトは、モダナイゼーションジャーニー全体を通じて使用できます。分解の計画では、インサイトが実際の依存関係とアーキテクチャの境界に基づいてモノリシックアプリケーションを管理可能なドメインに分解する方法の理解を提供します。技術的負債の分析は、リスク、影響、ビジネス価値に基づいた順序付きの作業を確保し、モダナイゼーションの各フェーズの優先順位を決定します。詳細なコンポーネント分析は、システムのどの部分が変換の候補であり、どの部分が完全な置き換えの候補であるかを示すことで、リファクタリングの決定を明確にします。ビジネスステークホルダーにとっては、抽出されたビジネスロジックがモダナイゼーション投資のビジネスケースを構築するために必要なナラティブを提供します。これを、後続のすべてのステップをより意図的でより良い情報に基づいたものにする基盤と考えてください。 ベストプラクティス 変換を実行する前に、結果に影響を与える可能性のある既知の問題や制限事項を文書化し、注力すべき特定の懸念領域を特定してください。 変換をターゲットを絞ったインサイトに導くために明確な追加コンテキストを提供し、出力を充実させることができる関連するアーキテクチャ図やドキュメントを含めてください。 分析が完了したら、チームとして技術的負債の分析結果をレビューし、技術的な重大度だけでなくビジネスへの影響に基づいて修正の優先順位を決定してください。 インサイトをスプリント計画と長期的なロードマップに活用し、技術者と非技術者の両方のステークホルダーとドキュメントを共有して、全員がシステムの全体像を理解できるようにしてください。 トラブルシューティング 結果に具体的なインサイトが不足している場合 出力が一般的すぎると感じる場合、最も効果的な修正方法は、エージェントにより明確な方向性を与える additionalPlanContext を通じてより詳細なコンテキストを提供することです。認証、決済処理、特定のサービスレイヤーなど、最も関心のある注力領域やドメインを指定し、エージェントがよりターゲットを絞った分析結果を生成できるように、既存のアーキテクチャドキュメントや図を参考資料として含めることを検討してください。 分析が完了しない場合 分析が完了できない場合は、エージェントが自力で解決できない可能性のある依存関係や設定ファイルの欠落を確認し、プロセスに干渉する可能性のあるコミットされていない変更がない、クリーンな状態の Git リポジトリであることを確認してください。大規模または複雑なコードベースの場合は、エージェントをガイドするために焦点を絞った additionalPlanContext を提供してください。 ドキュメントが広範すぎる場合 生成されたドキュメントが必要以上に広い範囲をカバーしている場合は、 additionalPlanContext でモジュールやドメインを指定してスコープを絞ってください。また、リポジトリ全体ではなく特定のサブディレクトリに対して分析を実行することもできます。これにより、システム全体の出力を確認する必要なく、最も重要な領域に焦点を当てた実行可能なインサイトを得ることができます。 まとめと次のステップ コードベースを理解することは、モダナイゼーション成功の基盤です。AWS Transform の包括的コードベース分析は、数か月の手動ドキュメント作成を数時間の AI によるインサイト生成に変換します。これにより、コードを変更する前に十分な情報に基づいた意思決定を行うための明確さが得られます。この基盤があれば、リアクティブではなく戦略的にモダナイズでき、レガシーアプリケーションをビジネスを推進するスケーラブルで保守可能なシステムに変えることができます。 次のステップとして、パイロットモダナイゼーションプロジェクトから始めてください。以下の追加リソースを確認し、レガシーコードベースに対して包括的コードベース分析を実行してください。アーキテクチャのインサイトを分解の計画に活用し、技術的負債の分析結果に基づいてモダナイゼーションの各フェーズの優先順位を決定し、抽出されたビジネスロジックをステークホルダーと共有してアラインメントを構築してください。定期的に再実行して進捗を追跡し、モダナイゼーションの取り組みが計画した成果を達成していることを検証できます。 追加リソース AWS Transform custom Documentation AWS Comprehensive Codebase Analysis Getting Started with AWS Transform Quotas for AWS Transform Ask questions on re:Post 著者について Damilola Odeleye Damilola Odeleye は、Amazon Web Services (AWS) のシニアテクニカルアカウントマネージャーです。エンタープライズ組織と連携し、クラウドのモダナイゼーションを加速させ、ビジネスに大きなインパクトをもたらす成果を推進しています。モダナイゼーションと AI/ML の両分野を専門とし、テクノロジーを長期的なビジネス成長と整合させることに注力しています。 Srinivas Ganapathi Srinivas Ganapathi は、Amazon Web Services のプリンシパルテクニカルアカウントマネージャーです。カナダのトロントを拠点とし、ゲーム業界のお客様と協力して、AWS 上で効率的にワークロードを実行できるよう支援しています。

はじめに はじめにNTT西日本の長谷川です。 本記事では、セキュリティ業界の有志で運営している「MINI Hardening」というコミュニティのメンバーにより開発された、サイバー攻撃を想定したインシデント・レスポンスを体験するためのトレーニングツール「ZANSIN」の体験談と自身で環境を構築する際の手順と注意点をまとめています。 ※Hardening とは情報セキュリティ分野においてセキュリティ強化演習を指す用語です。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN セキュリティの勉強をすすめていると、よく攻撃手法やその脅威をテキストとして見ることはありますが、座学だけではその動きや脅威はあまり実感できません。 このZANSINはそれを体験できるツールですので、セキュリティのスキル強化やセキュリティ対策の重要性を理解し、スキルアップに役立てるべく紹介していきます。 トレーニング環境はローカル環境やプライベートゾーンなど外部から悪用されない安全な環境で構築してください。 許可なくインターネットサイトを攻撃することは法律（不正アクセス禁止法等）に抵触する行為となるため、絶対に行わないでください。 この「ZANSIN」を用いて以下の習得が期待できます。 実践的なセキュリティ強化スキル 脆弱性をついた攻撃とその対策方法 セキュリティ対策の重要性 本ツールは体験・トレーニングツールとして公開されているため、初級～中級を主なターゲットにしています。 対象読者 本記事が想定する対象読者は以下の通りです。 サーバーのセキュリティ対策に興味があり、そのスキルを伸ばしたい方 サイバーセキュリティ対策の腕試しをしたい方 サイバーセキュリティ対策の実践力を鍛えたい方 目次 はじめに 対象読者 目次 1.背景 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 2-2. 脅威モデリングと対策検討 2-3.ZANSINのトレーニングシナリオ 2-4.ゲームサーバー（Trainingサーバー）の構成 2-5.トレーニング例 3.ZANSINを使ったトレーニングイベントに参加してみて 3-1.チームでのトレーニング 3-2.実際のトレーニング結果 3-3.トレーニングを受けて感じたこと 4.ZANSINの構築方法 4-1.要求スペック 4-2.構築場所 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） 4-4.クラウド環境におけるZANSIN事前設定（AWS＆Azureのみ実施) 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） 4-6.ZANSINトレーニング開始 5.最後に 執筆者　 参考資料・出典 商標　 免責事項 1.背景 セキュリティの勉強を進めていくと、さまざまな攻撃や脆弱性について語られることがありますが机上では学べないものが多く、以下のように悩むことがあります。 実際に脆弱性をついた攻撃などを体験する機会がない。 脆弱性を確認するにも環境構築からが大変。 実践的なスキルを身につける環境が欲しい。 私自身も、頭では理解しているつもりでも「実際に何が起きるのか」が結び付かず、もどかしさを感じていました。 このような悩みを持つ方も多いのではないでしょうか？ こういった机上では学べないことを実際に体験してみましょう。 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 ZANSIN は Ubuntu®で構築されたControlサーバーとTrainingサーバーの2台で構成され、Trainingサーバーには「MINI QUEST」というWeb ゲームが稼働しています。 ControlサーバーはTrainingサーバーに対してサイバー攻撃を行います。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN 利用者はTrainingサーバーに潜む脆弱性を特定し、対策を施していくことでサイバー攻撃や不正行為に対して迅速かつ効果的な対応スキルを体験的に学ぶことができます。 実行される攻撃例 不正ログイン バックドア設置 ゲームサービス妨害 ゲームのチート行為 これらの攻撃に対する対策を通してセキュリティ対策スキルを養っていきます。 トレーニングの性質上どういった攻撃が実行されるかは明示しませんが、よく耳にする攻撃からの対策方法を学ぶことができます。 （あくまで防御について学ぶトレーニングツールであり、攻撃手法が学べるものではありません） ZANSINはあえて複数の脆弱性を含んだシステムを用意し、攻撃を受けながら守り方を学ぶという設計思想となっています。 実運用では本来避けるべき構成や設定も含まれていますが、それらを「なぜ危険か」「どう検知し、どう是正するか」を体験的に理解することを目的としています。 ※ZANSINは教育目的専用のツールです。実際の本番システムへの攻撃に応用することは法律で禁止されています（不正アクセス禁止法等） 2-2. 脅威モデリングと対策検討 事前資料から潜在的な脆弱性の洗い出し、攻撃シナリオの想定を行うことでセキュリティ設計の基本も体験できます。 ぶっつけ本番でおこなって体験するのもいいですが、効果的なトレーニングにするためにはしっかり事前準備するとより効果が得られます。 2-3.ZANSINのトレーニングシナリオ ZANSINは以下の指示に従ったトレーニングを行います。 Ubuntuで構築されたゲームサーバー（Trainingサーバー）が公開されましたが、脆弱性を含んでいるようです。 ゲームサーバー（Trainingサーバー）にはMINI QUESTと呼ばれるブラウザゲームが稼働しています。 ゲームサーバー（Trainingサーバー）がサイバー攻撃にさらされています。サイバー攻撃に対応しシステムを保護してください。 稼働しているMINI QUESTをチート行為から守ってください。 トレーニング時間（240min）の間に多様な攻撃が行われます。どの程度脆弱性が修正されたかで評価します。 2-4.ゲームサーバー（Trainingサーバー）の構成 ゲームサーバーにはUbuntu上に構築されたNGINX®、MySQL®、Redis®、Docker®で動作しており、構成は概略として以下となっています。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN このゲームサーバには多くの脆弱性が潜んでいます。 トレーニングを受けるユーザーはこの構成図と配布されるGAME API設計書から脆弱性の予測と洗い出しを行い、トレーニングに挑みます。 2-5.トレーニング例 トレーニングに影響が出るといけないので、多くは書けませんが、 実際にどのような攻撃が行われるか一つの例をあげてみます。 Trainingサーバーにはいくつかの脆弱性があります。 その中の一つに脆弱なパスワードを使っているユーザーがいます。 それを放置しているとパスワードを推測されて不正ログインされた結果、管理者権限を奪われ、バックドアとなる不正ユーザーが作成されます。（不正ユーザーが作成される経路は複数用意されています） ログなどから不審なユーザーが登録されていることを見つけることができれば、その後バックドア経由での攻撃を防げるかもしれません。 他にもセキュリティを勉強しているとよく目にするいろいろな攻撃が仕掛けられます。 ログや配布資料をもとに攻撃を特定し対策をしていきます。 3.ZANSINを使ったトレーニングイベントに参加してみて 実際に私もZANSINを使ったトレーニングイベントに参加してみました。 3-1.チームでのトレーニング トレーニングイベントでは参加者は4～5人のチームに割り振られました。 チームごとに提供された事前情報をもとにサーバーを防御するというものでした。 このときはZANSINというものは知っていたので、実際に体験するいい機会でした。 イベントでは初対面同士でチームが構成されてトレーニングに臨みました。 写真：社内で実施したトレーニングイベントの様子 トレーニング実施前の準備時間に、与えられた情報から簡単に以下の役割を決めました。 全体管理 ログ等からの分析 実際の改修、修復 3-2.実際のトレーニング結果 実際にトレーニングを行った結果はボロボロでした。 （普段から専門的にセキュリティ対策に携わっていないと初見ではかなりやられると思います） ですが、今まで机上でしか知ることがなかった攻撃が目の前で実行されます。 それをログなどから追いかけ対策を講じていくというのは非常に多くの学びがありました。 紹介していたようにWeb ゲームが動いていますが、どうしようもなく破壊されたときには頭を抱えるほどでした。 3-3.トレーニングを受けて感じたこと 実践的な経験を通じたトレーニングの有効性を改めて実感しました。 私は即席のチームでイベントに臨みましたが、いろいろな対応が必要になるためチームビルディングの重要性を感じました。 トレーニングに挑む際には以下にあげたような役割を決めて挑むほうが、慌てず対処できると思います。 全体管理 ログ分析（攻撃監視） 対策（スクリプト・設定修正） ZANSINは公開されているので、自身で環境構築をすればこのトレーニングを通してスキルの向上に役立てられそうです。 実際、1回ですべて対策できるとはとても思えないくらい多様な攻撃が行われます。 繰り返しトレーニングしてスキルを高めていきたいと思わせるツールです。 4.ZANSINの構築方法 自身でトレーニングをするためのZANSINを構築していきます。 ZANSINはUbuntu Serverで動作しますが、ControlサーバーとTrainingサーバーの2台が必要になります。 ZANSINの要求スペックは低いのでローカル環境でも十分構築できると思います。 Ubuntu Serverは20.04以上が必要とされており、22.04までは正常にインストールできることが確認されています。 24.xではインストールスクリプトを修正すればインストールが可能とコミュニティへの報告もありますが、22.04で構築することをお勧めします。 4-1.要求スペック それぞれのサーバーに必要とされる最低スペックは以下のとおりとなっています。 コア数 メモリ 記憶域 Controlサーバー 1 2GB 30GB Trainingサーバー 1 2GB 30GB 記憶域は30GBとなっていますが、実際は10GB程度しか使っていないことを私の環境（Ubuntu 22.04, 2026年3月時点）で確認しているため、節約したい場合は20GB程度でも動作します。 メモリは2GBとなっていますが、1GB以上のSWAPがあればメモリは1GBでも動作します。 4-2.構築場所 ZANSINが要求するスペックは高くありません。 古いPCを2台用意する方法もありますが、仮想環境を用意して構築するほうが現実的かもしれません。 AWS®やAzure®といったクラウド環境であれば手軽に構築を始められるかわりにローカル環境の構築より手順が多くなっています。 クラウド環境構築に必要な追加手順や外部から悪用されないセキュリティ設定などに不安があるのであれば、ローカル環境でHyper-V®やVirtualBox®などを用いるほうが手軽に構築できます。 （ローカル環境構築の場合も外部ネットワークに公開しないなどのセキュリティを考慮した設定は行ってください。） ※クラウド環境の場合いくつかの追加モジュールが初期インストールされていないため、手動追加する必要があります。 （”4-4.クラウド環境（AWSやAzure）におけるZANSIN事前設定”や”4-5.ZANSIN構築手順”の手順5～6が必要） 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） ※クラウド環境は、Ubuntuの22.x系を選択し、4-4項を実施。 以下にインストール時のパラメータを示す。 Controlサーバー、Trainingサーバー用に2台用意し、同じ設定で構築する。 インストール手順については公式ドキュメント等を参照してください。 項目 値 備考 OS Ubuntu Server 22.x インストールメディア・iso等 インストールタイプ Ubuntu Server（minimized） 両サーバー共通 Profile:Your name zansin 両サーバー共通 Profile:Your servers name 例：ControlServer、TrainingServer 運用上わかりやすい名前を任意で設定 Profile:Pick username zansin 両サーバー共通 Profile:Choose a password 任意のパスワード 両サーバー共通 SSH設定 チェック 利用できるようチェックする ローカル環境で構築する場合、トレーニング受講者のみがアクセスできる安全なプライベートネットワークにControlサーバー、Trainingサーバーを構築してください。 4-4.クラウド環境におけるZANSIN事前設定（ AWS＆Azureのみ実施 ) AWSやAzureを利用した場合の追加となる事前設定。 （Hyper-VやVirtualBox等ローカル環境で構築の場合は不要） この設定を行わないとAWSやAzureではインストールスクリプトが正常に終了しなかったり、トレーニングが正常に行えないため、必ず実施する。 自分でOSからインストールする場合は不要。 1.ネットワークセキュリティ設定（ トレーニング用途限定 ） トレーニングに必要な以下のネットワーク通信を許可する。 プロトコル ポート TCP 5555 TCP 3000 TCP 22 TCP 6379 TCP 80 TCP 3306 TCP 443 TCP 2375 ICMP (推奨) これらのポートへの接続ができなければ、正常なトレーニングが行えないため、トレーニング環境に限定して通信を許可すること。 ※これらのポートはトレーニング用途で解放するもので、そのままでは脆弱性につながるものがあります。 ※本番環境では解放するポートについては用途を確認し十分注意して解放すること。 ※特にTCP:2375の解放は本番環境では注意すること。 勘の鋭い人はここからどんな攻撃が行われるか予測できるかもしれませんね。 クラウド環境の場合、外部からの不正アクセスに対する設定を行ってください。 以下が一例ですが、このような設定を推奨します。 ・ トレーニング受講者のみがアクセスできるようなIPによるアクセス制限の追加。 ・ 以下のようなSSHのみ許可した踏み台サーバを用意し、踏み台サーバからポートフォワード機能を利用してトレーニング環境へアクセスする。 （踏み台サーバの構築、ポートフォワード機能については本記事では取り上げておりません） 2.zansinユーザーの作成 アカウント：zansinを作成する。 コマンド例 $ sudo useradd zansin $ sudo passwd zansin パスワードは任意で登録。 ただしControlサーバーとTrainingサーバーでパスワードは共通にしておくこと 3.ZANSIN展開用ホームフォルダの作成 以下の例を参考にホームフォルダを作成する コマンド例 $ sudo mkdir /home/zansin $ sudo chown zansin:zansin /home/zansin 4.sudoersの追加 以下コマンド例を参考にアカウント:zansinでsudoが使えるようにする。 コマンド例 $ sudo usermod -aG sudo zansin 5.apache2の停止 クラウド環境ではapahe2がインストール済みで自動起動している場合がある。（AWSでは確認済み） ZANSINの構築時には競合するため、停止させておく。 コマンド例 $ sudo systemctl stop apache2 $ sudo systemctl disable apache2 6.SWAP作成（推奨） ※必須ではないものの、やっておいた方が安定性とレスポンスが向上する コマンド例 $ sudo mkdir /swap $ sudo dd if=/dev/zero of=/swap/swapfile bs=1M count=2048 $ sudo chmod 600 /swap/swapfile $ sudo mkswap /swap/swapfile $ sudo swapon /swap/swapfile $ sudo echo ‘/swap/swapfile none swap sw 0 0 ‘ | sudo tee -a /etc/fstab 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） ZANSINをインストールして環境を構築します。 一番の山場で時間がかかります。 ここは手順通りに進めていても不安になりやすい箇所なので、焦らず進めることが大切です。 ※AWS、Azureで構築した場合はインストーラがモジュール不足でエラーを出し、正常にインストールできません。5及び6の修正作業が必要 1.sshdの設定変更（Controlサーバー、Trainingサーバー両方で実施）　 ※本番環境では非推奨 ControlサーバーはパスワードログインのSSHを通してTrainingサーバーを制御しています。 そのため両サーバーでSSHのパスワードログインを有効にします。 パスワードログインの有効化 /etc/ssh/sshd.confの修正 以下コメントアウト　もしくは追記 PasswordAuthentication yes ※SSHのパスワードログインはセキュリティリスクにつながる可能性があります。 本番環境では特別な理由がない限りは推奨されません。 2.ZANSINセットアッスクリプトのダウンロード（Controlサーバーで実施） ZANSINをインストールするためのスクリプトを入手します。 以下は ZANSIN のインストールスクリプトを取得するコマンドです。 このスクリプトは GitHubで公開されています。 https://github.com/ZANSIN-sec/ZANSIN コマンド例 $ cd /home/zansin $ wget https://raw.githubusercontent.com/ZANSIN-sec/ZANSIN/main/zansin.sh ※このコマンドで指定しているのはGitHubの公開リポジトリへの直接リンクである。そのため将来リポジトリ構成が変更された場合にリンク切れとなる可能性がある。その場合はGitHubから変更されたリンクを確認すること。 3.インストールスクリプト実行（Controlサーバーで実施） インストール作業はカレントディレクトリを/home/zansinに変更して実施。 コマンド例 $ cd /home/zansin $ chmod +x zansin.sh $ ./zansin.sh 4.インストールスクリプト（Controlサーバーで実施） スクリプトを実行するとインストーラが走ります。 インストールに必要な情報として以下を入力するよう求められます。 sudoパスワード（設定したzansinパスワード） ControlサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） TrainingサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） zansinパスワード：zansinのパスワード（設定したパスワード） 必要な情報を入力してインストールが開始されます。 マシンスペックにもよりますが、データ転送に時間がかかります。 要求最低減のスペックの場合、30分以上かかる場合もあります。 特にコンテンツデータの転送は時間がかかり止まってるように見えますが、気長に待ちましょう。 ※クラウド環境で実行した場合モジュール不足でエラーが表示されます。（インストールは最後まで走る） ※クラウド環境で構築する場合、以下を追加で実行する必要があります。（AWS、Azure以外では不要） 5.Controlサーバーでのモジュール追加（ AWS、Azure環境のみ実行 ） ※AWS、Azureで構築した場合はインストーラがPython®のモジュール不足でエラーを出し、正常にインストールできないためこの作業でモジュールを手動追加します。 エラーが出る不足モジュールを追加します。 $ source /home/zansin/red-controller/red_controller_venv/bin/activate $ pip3 install python-nmap $ pip3 install bs4 $ pip3 install paramiko $ pip3 install requests $ pip3 install docopt $ pip3 install aiohttp 6.インストールスクリプト再実行（ AWS、Azure環境のみ実行 　Controlサーバーで実施） 以下コマンドでインストールを再実行します。 $ ./zansin.sh 4-6.ZANSINトレーニング開始 構築作業お疲れさまでした。 以上でZANSINの構築は完了しました。 ここからは、ZANSINを実際に動かしてみましょう。 最初はすべての攻撃に対応できなくても問題ありません。 私も初回は思うように対処できず、かなり戸惑いました。 特にこういったインシデントに初めて触れる人は以下を目標とするくらい気楽にやる方がいいかもしれません。 ログやWeb画面で攻撃を目の当たりにする （何が起きているかを追えるようになるとさらにGood） なにか一つ対処できた （こうすれば対処できたといった振り返りができただけでも十分） ZANSINでトレーニングを開始する場合は以下を参考にコマンドを実行します。 SSHでControlサーバーに接続しトレーニング実行のコマンド以下を実行します。 通常モードでトレーニング開始 ~$ source /home/zansin/red-controller/red_controller_venv/bin/activate ~$ cd /home/zansin/ red-controller/ ~$ python3 red_controller.py -n ***** -t ***.***.***.*** -c ***.***.***.*** -a 1 python3 red_controller.py　オプションパラメータ補足 -n　Trainingユーザー名指定（自由に指定可能） -t　TrainingマシンのIP指定（AWSではプライベートIPV4アドレス） -c　ControlマシンのIP指定（AWSではプライベートIPV4アドレス） -a　攻撃シナリオ（上記例は1） 標準で登録されている攻撃シナリオは以下のとおり　0：デバッグシナリオ、1：標準シナリオ、2：簡易シナリオ（動作チェック等でなければ1を選択すること） コマンド例： Trainingユーザー名：test01 TrainingマシンのIP：10.10.10.1 ControlマシンのIP：10.10.10.2 攻撃シナリオ：１ $ python3 red_controller.py -n test01 -t 10.10.10.1 -c 10.10.10.2 -a 1 5.最後に 環境を用意する手間はありますが、仮想化技術を活用することで、トレーニング環境は容易に構築できます。 こういったトレーニング環境を活用することで、セキュリティインシデントを他者に影響与えることなく体験することができます。 セキュリティに興味のある方は、力試しやスキルアップの機会として活用を検討してみてください。 きっとセキュリティ設計やトラブルシュートに役立つ学びがあると思います。 執筆者　 長谷川 喬一（NTTビジネスソリューションズ（株） エンタープライズビジネス営業部 ネットワーク＆ソリューション推進担当） サーバーやクラウド、セキュリティの案件支援及びエリアのPMOに携わっています。 参考資料・出典 GitHub - ZANSIN-sec/ZANSIN · GitHub 商標　 「Ubuntu®」は、Canonical Ltd. の登録商標です。 「Hyper‑V®」および「Azure®」は、Microsoft Corporation の登録商標です。 「VirtualBox®」および「MySQL®」は、Oracle America, Inc. またはその関連会社の登録商標です。 「AWS®」は、Amazon Technologies, Inc. またはその関連会社の登録商標です。 「NGINX®」は、F5 Networks, Inc. の登録商標です。 「Redis®」は、Redis Ltd. の登録商標です。 「Docker®」は、Docker, Inc. の登録商標です。 「Python®」は、Python Software Foundation の登録商標です。 免責事項 本記事の情報を利用した結果として生じた損害・トラブルについて、当社および執筆者は一切の責任を負いかねます。