実績 - 脆弱性診断

Service 19

脆弱性診断

クラウドセキュリティ脆弱性診断・直接改修エンジニアリング

CONCEPT

攻撃の自動化に対するアーキテクチャ遮断とコード堅牢化の実装

セキュリティチェックシートの項目はすべて満たしている。

外部機関の脆弱性診断も受け、指摘された箇所は塞いだはずだ。

それでも、他社の情報漏洩ニュースを見るたびに「自社のシステムも同じ手口で侵入されるのではないか」という疑念が拭えない現場は少なくありません。

この懸念は、決して杞憂ではありません。

従来の対策は、「WAFの設置」「通信の暗号化」「パスワードのハッシュ化」「24時間体制の監視」といった、手続きや運用ルールを満たすことを主眼に置いてきました。しかし、昨今のインシデント事例を客観的に確認すると、それらの基準を形式上クリアしたシステムが、驚くほど単純であっけない設定の隙間から侵入を許しています。

さらに、既存のセキュリティ対策には構造的な問題があります。

会社
担う範囲
診断会社
穴を見つけて紙に書くだけで、直す責任は負わない。
大手SIer
監視センターで人を見張らせるだけで、他社が作ったプログラムには触らない。
クラウド会社
サーバーの土台を置くだけで、プログラムの中身（他人のデータが覗き見できる状態）は管轄外。

結果として、重大な欠陥が見つかっても、誰も直さないまま放置されてきました。

ARCHECOが提供するのは、レポート書類を作るためのセキュリティではありません。「攻撃者と同じAIツールを放って機械的に穴を探し、見つかった穴の修理（クラウド設定とプログラムの書き換え）まで自分たちの手で完了させ、二度と同じ穴が空かない自動チェック機を開発ラインに取り付ける」という、実務を一括して引き受けるエンジニアリングです。

  1. 攻撃は単純な試行の繰り返しで、開いている1か所に届きます。
  2. 同じ試行を先に当てて、開いている所を見つけます。
  3. 設定とコードを直し、同じ試行をもう一度当てて止まることを確かめます。

STRUCTURAL SHIFT

昨今のサイバー攻撃における構造変化

攻撃の手口は「高度」ではなく、驚くほど「単純で、あっけない」

ニュースでは「高度なサイバー攻撃」と報じられますが、実際の侵入原因を調べると、技術的には拍子抜けするほど単純なミスばかりです。

URLの数字を変えてみる

.../orders/1001 の数字を 1002 に書き換えただけで、他人の注文履歴や請求書が画面に出てきてしまう（認可制御の欠落：BOLA/IDOR）。

消し忘れた裏口を探す

開発やテストのときに一時的に開けて、そのまま閉じ忘れていたネットワークの接続口（ポート）から侵入される。

クラウドの鍵の開けっ放し

インターネット全体に公開されたまま放置されたファイル置き場（S3バケット等）から、顧客データが丸ごとダウンロードされる。

何でもできる権限の放置

システムが止まるのを怖がり、クラウドの設定で何でも操作できる万能キー（全権限）をプログラムに持たせてしまう。

これらは映画に出てくるような天才ハッカーの技ではありません。「鍵が開けっ放しの窓をガチャガチャと回して探しているだけ」です。

昔は、この単純作業を人間が手作業で行っていたため、見つかるまでに猶予がありました。しかし現在では、自動化ツールやAIが、インターネット上のシステムに対してこの単純な確認を1秒間に数千回の頻度で機械的に繰り返しています。

100万箇所のうち99万9,999箇所をルール通りに施錠していても、開発者がうっかり忘れた「たった1箇所の鍵の開けっ放し」を、AIツールは数秒で見つけ出します。

攻撃側と防衛側における「投資対効果（ROI）の崩壊」

この変化は、攻撃側と守る側の経済性に決定的な差を生み出しています。

攻撃側のコストは「ほぼゼロ」

使い捨てのクラウド環境から自動スクリプトを回すため、IPが遮断されようが痕跡が残ろうが痛手を負いません。1回でも侵入できればデータ窃盗や身代金要求で莫大な利益を得られるため、探索の費用対効果（ROI）は極めて高くなります。

防衛側のコストは「高額な人件費の固定化」

日本企業が長年継続してきた「24時間365日の有人監視体制」「数百項目に及ぶチェックシートの運用」「年1回の手動診断」は、いずれも人月単価に依存した固定費です。1秒間に数千回飛んでくる機械的な探索に対し、アナリストがログを目視確認して電話連絡を取り合う運用では、通知を受領した時点でデータ侵害が完了しているケースが生じます。

人海戦術や書類作成にリソースを投じ続ける防衛モデルは、機械化された攻撃に対して構造上追いつかなくなっています。

COMPARISON

上記攻撃の変化に未対応な一般的なアプローチと、本エンジニアリングサービス

比較項目
従来の一般的なアプローチ
本エンジニアリングサービス
検証手法
年1回の手動チェック・定型ツールスキャン
攻撃者と同じAIツールによる網羅的な自動探索（模擬攻撃）
対策の重心
運用ルールの遵守、チェックシート、有人監視
侵入経路の全閉、エッジでの自律遮断、コードの最小権限
診断後の対応
指摘報告書（PDF）の提出、改修は顧客側へ丸投げ
クラウド設定（IaC）や修正コード（PR）を直接作成・適用
改修の証明
書面上の「対策完了報告」
改修後に同一の模擬攻撃を再実行し、遮断ログを提示
社内承認への対応
規定のチェック項目に縛られ、新技術の導入が停滞
サンドボックス（出島環境）での実証と対照表の提供
開発と運用
年1回の診断と、形骸化しやすい社内規程の順守
CI/CDによる自動検査 ＋ 継続的な構成監視と伴走

CHECKSHEET GAP

チェックシートに並ぶ要件と、実際の保護範囲の乖離

大手企業のセキュリティ対策確認票や外部委託先セキュリティチェックシート（FISC安全対策基準やIPAガイドライン等をベースにしたシート）に記載される代表的な要件は、基礎的な統制として一定の意義を持ちます。しかし、それらが保護する範囲と、昨今の攻撃手法との間には前提の乖離が存在します。

  1. 通信の盗聴防止対策（SSL/TLS 1.2/1.3の適用、HTTPSの強制）

    • 本来の保護範囲：公衆Wi-Fiや伝送路上の中継地点における第三者によるパケット盗聴・改ざんの防止。
    • 技術的実態：攻撃者自身が、自らの環境から「正規のTLSハンドシェイクを完了した正当なHTTPS通信」を通じて攻撃リクエストを送信します。安全に暗号化された経路の中を悪意あるリクエストが通過するため、通信の暗号強度自体は攻撃の抑止に寄与しません。

  2. 保管データの暗号化（Encryption at Rest、AES-256、KMS連携）

    • 本来の保護範囲：データセンターから物理ディスクが持ち出された場合や、ストレージスナップショットが第三者アカウントへ不正共有された際のデータ閲覧防止。
    • 技術的実態：攻撃者は物理ディスクを盗むのではなく、正規のWeb/APIアプリケーション経由でアクセスします。アプリケーションが稼働している状態では、DBエンジンがクエリに対して自動的に復号した平文データを返却します。認可ロジックに不備があれば、ディスクがAES-256で暗号化されていても、平文の顧客データがそのまま引き出されます。

  3. パスワードの不可逆暗号化保存（ソルト付きハッシュ化、ストレッチング）

    • 本来の保護範囲：データベース内の全レコードが流出した事後において、平文パスワードの即時特定と他サービスへの不正ログイン（パスワードリスト攻撃）を抑止すること。
    • 技術的実態：攻撃者の主目的は、パスワードの解析そのものよりも「暗号化されていない顧客データ（氏名・住所・生年月日・決済履歴・機密文書等）」の取得です。パスワードが強固にハッシュ化されていても、個人情報が引き抜かれれば重大インシデントとなります。ハッシュ化は漏洩自体を防ぐ防壁ではありません。

  4. Webアプリケーション層の防御（WAFの導入、シグネチャの日次自動更新）

    • 本来の保護範囲：SQLインジェクションやクロスサイトスクリプティング（XSS）など、既知の攻撃パターン（シグネチャ）を含む構文異常リクエストの遮断。
    • 技術的実態：AIが生成したコードや短期間で開発されたAPIで多発する「認可制御の欠落（BOLA/IDOR）」は、構文上100%正常なHTTPリクエストです。例えば、GET /api/v1/users/10001/invoice を 10002 に書き換えて送信するリクエストには不正な文字列が含まれません。シグネチャが存在しないため、WAF単体では正常な通信として素通りします。

  5. 運用監視・インシデント対応体制（24時間365日のSOC/MSS監視）

    • 本来の保護範囲：セキュリティ機器が「既知の脅威」として検知した事象について、手順書に基づく確認と一次連絡を保証すること。
    • 技術的実態：機械的な探索ツールが認可の穴を突いてデータを取得するまでに要する時間は、数秒から数分です。BOLA攻撃はWAFやIDSでアラートすら上がらないためSOCの監視画面には現れず、仮に「403多発」として検知されたとしても、アナリストがログを解析して連絡を入れる頃には送出は完了しています。

CONSEQUENCE

構造的な帰結

チェックシートの基準を満たすことは、企業のコンプライアンス管理において不可欠な手続きです。しかし、それらの項目にすべて適合していたとしても、「APIエンドポイントの認可ロジック」「不要ポートの全閉」「IAMの最小権限化」「コンテナの読み取り専用化」といった、現代の自動化攻撃が直接到達する境界線は、従来のチェックシートの枠組みからは抜け落ちています。

手続き上の確認を積み上げても、コードとインフラの物理的な隙間が開いている限り、侵入は成立します。必要なのは、事後監視の人員を増やすことではなく、「単純な試行が構造上成立しないアーキテクチャをコードで敷くこと」です。

  1. チェックシートの項目（通信と保管データの暗号化、パスワードの保護、既知の攻撃の遮断、有人監視）は、すべて満たしている状態です。
  2. APIの認可、不要なポートの閉鎖、IAMの最小権限、コンテナの読み取り専用化は、従来のチェックシートには項目がありません。自動化された攻撃は、正面の門の横から、この境界へ直接届きます。

INDUSTRY GAP

産業構造における分断と改修の空白

多くの企業において実効的なセキュリティ対策が進まない背景には、日本のIT産業における「4重の分断構造」が存在します。

探す
報告する
直す
確かめる
保ち続ける
診断会社
脆弱性を指摘して報告書を提出することが業務であり、他社のシステムを修正して本番障害を引き起こすリスクは負いません。
探す：担う
報告する：担う
直す：担わない
確かめる：一部を担う
保ち続ける：担わない
大手SIer
ガバナンス規程を整え、有人監視の運用保守を請け負うことが中心であり、個別システムの深いコード修正やIaCのリファクタリングには踏み込みません。
探す：担わない
報告する：担わない
直す：担わない
確かめる：担わない
保ち続ける：担う
インフラ会社
クラウド基盤の構築が業務範囲であり、アプリケーション内部の認可ロジック（BOLA）の不備までは管轄しません。
探す：担わない
報告する：担わない
直す：一部を担う
確かめる：担わない
保ち続ける：担わない
下請け開発会社
定められた納期と予算内で仕様を満たす画面と機能を実装することが主眼であり、高度なセキュリティ設計を独自に盛り込む余力やインセンティブを持ちません。
探す：担わない
報告する：担わない
直す：一部を担う
確かめる：担わない
保ち続ける：担わない

濃い印は担う範囲、薄い印は一部（診断会社の「確かめる」は再診断を契約した場合、インフラ会社は基盤まで、開発会社は決められた実装まで）。

この分業構造により、発注元企業は「診断会社からレポートを受け取り、SIerに相談し、インフラ会社に確認し、開発会社に改修を依頼するが、全体を統括して直す主体が存在しない」というバケツリレーに直面します。

攻撃側のツールが「インフラとコードの隙間」を横断して突いてくるのに対し、防衛側が組織ごとに縦割りで分断されている点に、現代の防衛における最大の空白が生じています。

APPROACH

構築現場の実態と大手企業組織へのアプローチ

  1. 01大手企業の現場では、標準になった安全な構成が、チェックシートの欄に合わないという理由で却下されてきました。
  2. 02監査や稟議の手続きは止めず、本番から切り離した環境での検証と、監査項目との対照表で、安全性を証明しながら導入します。
  3. 03テストの無い既存システムは、まず手前のエッジで守り、テストを自動で作ってから、最小限の改修を行います。

現場における「標準」と「チェックシート」の歴史的乖離

率直に記述すれば、私たちが提示している構成——「ポート全閉（SSM接続）」「コンテナのRead-only化」「IaC（Terraform）」「CI/CD自動スキャン」——は、技術的に突飛な新奇性を持つものではありません。モダンなWebサービスやSaaSを自社で設計・運用してきたエンジニアにとっては、過去3〜5年の間に完全に定着した「標準構成（基礎衛生）」です。

しかし、大手企業のシステム開発現場においては、この標準的な構成が長年にわたりセキュリティチェックシートと正面衝突してきました。

  • 構築側が「ポート22を全閉にし、AWS Systems ManagerでID認証と操作ログを完全自動取得する方が安全である」と提案しても、チェックシートに「保守用踏み台サーバーのIP一覧を記入する欄」が存在するために却下される。
  • 構築側が「WAFの多重投資よりもAPI認可層の一元改修と自動スロットリングに費用を充てるべきである」と提言しても、「大手の有人運用監視体制図が添付されていないと稟議が通らない」と退けられる。
  1. ポート22を全閉し、AWS Systems ManagerでID認証と操作ログを自動取得する方が安全でも、チェックシートに「保守用踏み台サーバーのIP一覧を記入する欄」があるために却下されます。
  2. WAFの多重投資よりAPI認可層の一元改修と自動スロットリングに費用を充てるべきでも、「大手の有人運用監視体制図」が添付されていないと稟議が通りません。

結果として、インフラをコードで堅牢に組むアプローチが形式基準の前に阻まれ、チェックシートを満たすための旧来の構成と人月監視が踏襲され続けてきました。その歪みが、現在自動化ツールによる侵入インシデントとして表面化しています。

組織の承認プロセスとガバナンス要件への適合手順

大手企業の情シスやセキュリティ管理部門は、監査役会、親会社、あるいは外部監査機関に対して「規定の安全基準に準拠している」と論理的に説明し、証跡を残す責任を担っています。どれほど合理的な最新技術であっても、既存のガバナンス体系や監査基準と接続できなければ、本番システムへの導入判断が下せないのは組織として正当な判断です。

この実務上の前提を踏まえ、本サービスでは既存の承認手続きを阻害せず、安全に検証・合意形成を進めるための2つの接続手順を標準プロセスとして組み込んでいます。

アプローチ 1：サンドボックス（検証用出島環境）による段階的検証

本番システム本体を直接改修する場合、変更管理手続きや委託先との責任分界点の調整に多大な工数と時間を要します。そこで、本体のネットワークおよびクラウドアカウント境界から完全に切り離された「サンドボックス（検証環境）」を構築します。

  • サンドボックス環境において、模擬攻撃の実施、IaCによるインフラ再構築、認可コード改修を先行して実施。
  • 既存の業務機能にデグレード（障害）が生じないこと、および攻撃試行が機械的に遮断されることを客観的なログと数値で証明。
  • 動作と安全性が検証された変更セットのみを、所定の社内変更管理手続きを経て本番環境へ安全に取り込む。
  1. 本体のネットワークとクラウドアカウントの境界から切り離したサンドボックスで、模擬攻撃、IaCによるインフラ再構築、認可コードの改修を先に行います。
  2. 既存の業務機能にデグレードが無いことと、攻撃試行が機械的に遮断されることを、客観的なログと数値で証明します。
  3. 動作と安全性を確かめた変更セットだけを、所定の社内変更管理手続きを経て本番環境へ取り込みます。

アプローチ 2：「監査基準対照マッピングシート」によるエビデンス提供

従来のチェックシート基準を否定するのではなく、「本サービスで実装する近代的なアーキテクチャが、従来の監査項目（安全基準）をどのような技術的根拠をもって代替充足しているか」を1対1で整理した対照表を作成し、成果物として納品します。

記述例

監査項目（従来のチェックシート）
本サービスでの代替充足
SSH踏み台サーバーのアクセス管理
AWS SSM Session Managerによるインバウンドポート全閉、IdP連携による多要素認証、および全操作コマンドログの改ざん不能ストレージ保管により、監査要件をより高い水準で代替充足

担当部門が社内監査や経営陣へそのまま提出・説明できる客観的なエビデンスを整えることで、形式基準と実効的な安全性の両立を支援します。

テストコードや仕様書が存在しないシステムへの対応方針

突貫で組まれたAI生成コードや、多段階の委託を経て納品された既存システムには、テストコードが1行も存在せず、仕様書も形骸化しているケースが存在します。この状態でアプリケーションコードを直接改変することは、予期せぬ機能破壊（デグレード）を招くリスクがあります。これに対し、無謀なコード書き換えを行わず、「2段階の防衛工学」を適用します。

  • 第1段階（エッジファンクションによる外付け遮断）：アプリケーション内部に手を触れず、エッジコンピューティング（Cloudflare Workers等）を用い、アプリの手前のネットワーク層で認可境界を外付けします。既存コードを1行も変更することなく、BOLA脆弱性を先行遮断します。
  • 第2段階（AIを用いた振る舞いテストの自動生成）：コード自体の改修が必要なエンドポイントに対し、現状の入出力ログからAIを用いてE2Eの振る舞い検知テストを網羅的に自動生成します。安全網となるテストコードを先に配備した上で、最小限の認可ミドルウェア改修を実施します。
  1. テストコードが無いシステムを直接書き換えると、機能が壊れるおそれがあります。上段はその失敗例です。
  2. まずアプリの手前で認可の確認を外付けし、アプリのコードを変えずに攻撃の通り道を塞ぎます。
  3. 現状の入出力の記録から、ふるまいのテストを自動生成します。動作を確かめる備えを置いてから、最小限の改修に進みます。

ARCHITECTURE

技術仕様：エッジコンピューティングと多層防衛アーキテクチャ

本サービスは、過去3〜5年の標準構成（基底レイヤ）を確実に固めた上で、昨今実効性が証明されている「エッジコンピューティングによる分散自律防御（発展レイヤ）」を実装します。

エッジファンクションによる分散認可と自律防御

従来はオリジンサーバー（AWS上のEC2やコンテナ）にリクエストが到達してからWAFやアプリケーションで判定を行っていましたが、大量の機械的探索をオリジンまで通すこと自体がリソースの逼迫を招きます。本サービスでは、Cloudflare Workers や AWS Lambda@Edge を活用し、オリジン到達前のエッジ層で処理を完結させます。

  1. 従来は、オリジンサーバー（AWS上のEC2やコンテナ）に要求が届いてから、WAFやアプリケーションで判定していました。大量の機械的探索をオリジンまで通すこと自体が、リソースを圧迫します。
  2. 本サービスでは、Cloudflare Workers や AWS Lambda@Edge を使い、利用者に近いエッジで、トークンと認可の検証、異常の抑制とチャレンジ、既存コードの保護を行います。オリジンには正規の要求だけが届きます。

エッジでのトークン・認可検証

世界中に分散配置されたエッジロケーション（CDN）において、リクエストに含まれるJWTやセッション情報をミリ秒単位で事前検証。不正な認可リクエストはオリジンサーバーに一切触れさせることなく、エッジで即座に403遮断します。

動的スロットリング ＆ チャレンジ挿入

単一IPまたは類似フィンガープリントからの異常なエラーレート（連続401/403）を検知した際、オリジンを介さずエッジ側でCloudflare Turnstile等の非侵襲的CAPTCHAを自動挿入、または段階的遅延（スロットリング）を付与し、探索スクリプトを停止させます。

既存コードの保護

オリジン側のコードを改修することなく、「リクエストパスに含まれるユーザーIDと認証トークン内のIDの整合性」をエッジファンクションで強制検証することで、レガシーシステムの認可不備を即時是正します。

2層の技術スタック対比

領域
従来のチェックシート構成例
過去3〜5年の標準構成（基底）
本サービスにおける実装（発展）
外部境界・検査
WAF単体配置（シグネチャ依存）
AWS WAF ＋ ALBレートリミット
Cloudflare Workers / Lambda@Edge によるエッジ認可・動的チャレンジ
リモート保守
SSH踏み台（EC2）/ ポート22開放
AWS SSM Session Manager
IdP連携 ＋ 端末証明書によるゼロトラスト接続（インバウンドポート全閉）
コンテナ実行基盤
永続サーバー管理（EC2 / OS管理）
ECS Fargate（Read-only Root）
不変コンテナ ＋ アウトバウンド完全制限（外部持ち出し遮断）
認可制御
コントローラー個別のif文記述
共通ミドルウェアによる検証
Policy as Code（Cedar / OPA） ＋ エッジ分散判定
認証情報管理
設定ファイル直書き、固定環境変数
AWS Secrets Managerでの暗号化
Workload Identity / OIDCによる永続キー完全撤廃
継続的検証
年1回の手動診断報告書
CI/CD（Trivy / Checkovスキャン）
AIプロンプト検査 ＋ ドリフト自動検知・IaC自動是正

PROCESS

提供プロセス（模擬攻撃から改修・再検証・伴走まで）

「指摘して終わり」とする従来の診断モデルと異なり、事前の自律模擬攻撃で急所を特定し、コード・IaCを直接改修した上で、再度同じ模擬攻撃を浴びせて遮断を立証する一貫したエンジニアリングプロセスを実施します。

  1. 合意した対象へ模擬攻撃を当て、外から届いて被害が大きい順に、設定とコードの修正を作ります。修正は本番から切り離した検証環境で試します。
  2. 最初と同じ攻撃を修正後の検証環境へ当て、止まったことを要求・応答や監査の記録で確かめます。修正と検証報告、監査向けの対照表を渡します。
  3. コードを出すたびに設定不備と既知の穴を検査する仕組みを開発ラインに組み込みます。現場へ実装の約束事と手順書を渡し、演習まで行います。
背景

Solution Flow

プロジェクトの進め方

Window decoration

01

STEP 01

Phase 1. 自律型模擬攻撃（現状の急所特定）

人手の手動確認にとどまらず、実際の攻撃者が使用する最新のAI探索エージェントや自動化スクリプトを用いて、外部から到達可能な全エンドポイントに対して網羅的な擬似攻撃を仕掛けます。

  1. 人手の確認にとどまらず、実際の攻撃者が使う最新のAI探索エージェントや自動化スクリプトで、外部から届く全エンドポイントに網羅的な擬似攻撃を仕掛けます。
  2. 探すのは3つ。アカウント間のデータ境界が破れるか（認可制御）、意図しない公開バケット・不要ポート・Security Groupの不備、IAMやサービスアカウントの権限の過不足です。
  3. 100万箇所のうち99万9,999箇所を施錠していても、たった1箇所の鍵の開けっ放しをAIツールは数秒で見つけます。だから同じ機械の速さで先に当てます。

Method

  • 認可制御（BOLA / IDOR）の総当たり探索：アカウント間のデータ境界が突破可能かをミリ秒単位で探索。

  • クラウドアタックサーフェススキャン：意図しない公開バケット、不要ポートの開放、Security Groupの設定不備を機械的に特定。

  • 過剰権限の抽出：IAMポリシーやサービスアカウントに付与された権限の過不足を網羅的に走査。

Phase 2. インフラ再設計 ＆ コード直接改修（堅牢化）

報告書の提出にとどまらず、弊社エンジニアがIaCおよびソースコードの修正パッチ（プルリクエスト）を作成し、適用します。

  1. 報告書の提出にとどまらず、弊社エンジニアがIaCとソースコードの修正パッチ（プルリクエスト）を作成し、適用します。
  2. 踏み台サーバー（ポート22）をやめてIDベースの接続へ。公開の入口はロードバランサー（443）に絞り、コンテナとデータベースはプライベートサブネットに完全に隔離します。
  3. コンテナのルートファイルシステムは読み取り専用にして外向きの不正な通信を制限。分散していた認可判定は、ミドルウェアやAPIゲートウェイ層へ集約します。

Method

  • リモートアクセスの刷新：踏み台サーバー（ポート22）を撤廃し、AWS Systems Manager (SSM) Session Manager等のIDベース接続へ移行。

  • ネットワーク境界の再設計：パブリックな入口をロードバランサー（443）に絞り込み、コンテナやデータベースをプライベートサブネットに完全隔離。

  • 実行環境の保護：コンテナのルートファイルシステムを読み取り専用（Read-only）に設定し、外部への不正なアウトバウンド通信をネットワーク層で制限。

  • 認可ロジックの一元化：各コントローラーに分散していた認可判定を整理し、ミドルウェアやAPIゲートウェイ層へ集約。

Phase 3. 模擬攻撃の再実行と遮断立証（検収テスト）

改修が完了したサンドボックス環境に対し、Phase 1で実施した模擬攻撃シナリオを再度実行します。

  1. 改修が完了したサンドボックス環境に、Phase 1で実施した模擬攻撃のシナリオを、そのまま再実行します。
  2. 見るのは2点。脆弱性が確実に無力化されているか、認可バイパスや不要ポート接続が機械的にブロックされて期待どおりのエラーログが残っているかです。
  3. 客観的な検証ログを顧客・監査部門へ示し、「安全性が担保された」ことを、事実に基づいて証明します。

Method

  • 脆弱性が確実に無力化されているか。

  • 認可バイパスや不要ポート接続が機械的にブロックされ、期待通りのエラーログが記録されているか。

Output

  • 客観的な検証ログを顧客・監査部門へ提示し、「安全性が担保されたこと」を事実に基づいて証明します。

Phase 4. セキュア・ハーネスの構築 ＆ 事業伴走（CI/CD組み込みと組織定着）

改修した安全な状態を維持するため、開発パイプラインに自動検査ゲートを組み込み、現場の自走を支援します。

  1. 開発パイプラインに自動の検査ゲートを組み込み、設定不備や既知の脆弱性を含むコードのマージを自動で抑止します。
  2. AI支援ツールで安全な実装パターンを強制する設定ファイルを配備し、認可バリデーションとテストコードをセットで出させる実装規律を、研修で浸透させます。
  3. 異常検知時に、疑わしいトークンの失効やコンテナの隔離を現場がすぐ実行できる運用手順（Runbook）を、現場チームと共同で作り、演習まで行います。

Method

  • CI/CD静的解析ゲート：GitHub Actions等にTrivyやCheckovなどの検査を組み込み、設定不備や既知の脆弱性を含むコードのマージを自動抑止。

  • AI開発向けルールファイル設定：Claude Code等のAI支援ツール利用時に、安全な実装パターンを強制する設定ファイル（CLAUDE.md）の配備。

  • AIコーディング実践ガイドライン研修：開発者がプロンプト任せにせず、認可バリデーションとテストコードをセットで出力させる実装規律を浸透。

  • インシデント初動の自動化手順引き継ぎ：異常検知時に現場が慌てず、疑わしいトークンの失効やコンテナの安全な隔離を即時実行できるRunbook（運用手順）を現場チームと共同作成・演習。

PLANS & COST

提供プラン・費用体系（サービス数連動 ＆ 安全期間設計）

本サービスは、保護対象となるシステム数（ドメイン/リポジトリ/クラウドアカウント系統数）に応じて、必要なエンジニア体制と期間が明瞭にスケールする体系をとっています。請負型の一括受託ではなく、シニアエンジニアチームをアサインする「スプリント型準委任契約」を採用し、大手組織の変更管理手続きや出島での検証期間を十分に織り込んだ「6〜9ヶ月」の安全な期間設計を基本とします。

  1. number 1

    スポット脆弱性診断 ＆ 直接遮断スプリント（2〜4週間）

    対象規模
    1プロダクト / 1クラウドアカウント
    体制
    セキュリティエンジニア 1〜2名
    期間
    2〜4週間
    費用
    250万円 〜 450万円（税別）
    内容
    成果物：自律模擬攻撃検証報告書、修正済みソースコード／Terraformコード（プルリクエスト納品）、社内監査向け対照マッピングシート
  2. number 2

    セキュア・アーキテクチャ再構築 ＆ パイプライン実装（6〜9ヶ月〜）

    対象規模
    1 サービス 〜 10〜30 サービス（規模別は下の表）
    体制
    シニアエンジニア 2〜3名 〜 専任アーキテクトチーム 5〜8名
    期間
    6 ヶ月 〜 9〜12 ヶ月〜
    費用
    月額 350万円 〜 1,500万円〜（税別）
    内容
    本番稼働中のシステムを対象に、サンドボックス環境を活用して無停止でインフラ境界および認可層を全面再構築。エッジファンクションの実装からCI/CDセキュリティゲートの配備までを一気通貫で伴走します。
  3. number 3

    継続的セキュア・ハーネス伴走プラン（月額更新・ストック）

    対象規模
    1〜3サービス 〜 10サービス以上
    体制
    大規模（10サービス以上）は専任エンジニア定常アサイン
    期間
    月額更新（最低契約期間6ヶ月〜）
    費用
    • ベース費用（1〜3サービス）：月額 120万円 〜 150万円（税別）［月次AIレッドチーミング、ドリフト監視是正、コードレビュー枠20〜30時間、監査レポート発行］
    • サービス追加オプション：1サービス追加ごとに ＋月額 20万円〜30万円（税別）
    • 大規模（10サービス以上）：個別見積（月額 250万〜400万円規模）
    内容
    アーキテクチャ再構築後、現場がAI等を活用して開発を継続する中で、設定の自然腐敗（ドリフト）や新たな認可不備の混入を防ぐための定常伴走プランです。管理対象となるサービス数に応じてスケールします。

2. セキュア・アーキテクチャ再構築 ＆ パイプライン実装の規模と費用

プラン規模
対象システム数
推奨期間
体制
費用目安（税別）
単一基幹プロダクト
1 サービス
6 ヶ月
シニアエンジニア 2〜3名
月額 350万〜450万円（総額 2,100万〜2,700万円）
事業部マルチサービス
3〜5 サービス
6〜9 ヶ月
アーキテクト＋エンジニア 3〜4名
月額 500万〜700万円（総額 3,000万〜6,300万円）
全社・グループ統合
10〜30 サービス
9〜12 ヶ月〜
専任アーキテクトチーム 5〜8名
月額 1,000万〜1,500万円〜（総額 9,000万〜1億8,000万円）

※ 10〜30サービス規模における「共通基盤化（スケールメリット）」の設計：全社共通基盤（共通Terraformモジュール、共通エッジ認可基盤、全社CI/CDテンプレート）を先行構築した上で各サービスを順次接続していくアプローチをとることで、1サービスあたりの改修単価を大幅に圧縮します。

CONTRACT & SCOPE

契約体制・技術適用範囲・検証独立性の定義

エンタープライズにおける実務導入と法務・ガバナンス審査を円滑に進めるため、責任分界、対応技術スタック、および診断の客観性担保方針を以下のように定義しています。

法的責任分界点と契約形態（デグレード防止と免責の設計）

本サービスは、既存システムの稼働安定性を最優先とし、請負契約ではなく「スプリント型準委任契約に基づく技術支援」として提供されます。

成果物の定義

ARCHECOの直接成果物および納品対象は、「サンドボックス（検証用出島環境）において機能テストおよび振る舞い検証をパスしたソースコードの修正パッチ（プルリクエスト：PR）およびIaC定義ファイル」となります。

本番適用の責任分界

本番環境への最終的なマージおよびデプロイ実行（リリースの承認ボタン押下）は、システムの全体業務仕様と運用権限を保持する顧客企業側のテックリードまたは指定の保守ベンダー様が実施・判断するものとします。

この境界設計により、予期せぬ業務仕様の齟齬によるデグレードリスクを完全に管理し、顧客企業および既存保守ベンダーのガバナンス規程と矛盾することなく安全な改修を推進します。

対象技術スタックと適用境界（対象範囲の明確化）

高い堅牢性と再現性を担保するため、ARCHECOが直接改修とアーキテクチャ再設計を引き受ける技術領域、および本サービスの対象外とする境界線を明確に定めています。

対応クラウド基盤

AWS（Amazon Web Services）、GCP（Google Cloud Platform）

エッジ・ネットワーク層

Cloudflare（Workers / Pages / Turnstile / Zero Trust）、AWS Lambda@Edge

コンテナ・実行基盤

Docker、AWS ECS（Fargate）、AWS EKS / GKE（Kubernetes）

インフラストラクチャ・アズ・コード（IaC）

Terraform（OpenTofu）、AWS CloudFormation / CDK

対応アプリケーション言語・フレームワーク

Go、TypeScript / JavaScript（Node.js, Next.js）、Python（FastAPI, Django, Flask）

対象外（スコープ外）領域

オンプレミス専用データセンター環境、メインフレーム（COBOL等）、レガシーERPパッケージの専用内部言語、およびソースコードの提供や検証環境の分離が不可能なプロプライエタリ環境は本サービスの直接改修の対象外となります（エッジ層での外付け遮断のみ対応可能な場合があります）。

診断と検証の客観性担保（第三者診断レポート持ち込み対応）

自律模擬攻撃から直接改修までを一気通貫で実施することに伴う「自作自演（利益相反）」の懸念を完全に排除するため、以下の客観性担保方針を標準としています。

機械的ログによる客観証明

自律型模擬攻撃で出力される検証ログは、ブラックボックスな主観判定ではなく、オープンなHTTPリクエスト/レスポンスログ、通信パケット、およびAWS/GCPの監査ログ（CloudTrail等）に基づく機械的な客観事実として開示されます。

他社診断レポートの持ち込み改修対応

顧客企業がすでに他社の第三者機関から受領している既存の脆弱性診断報告書（PDF）を持ち込みいただき、その指摘項目を解消するための直接改修およびIaC再構築からプロジェクトを開始することも完全に対応しています。

これにより、第三者機関による中立的な診断評価と、ARCHECOの高度な直接改修エンジニアリングを柔軟に組み合わせた監査体制を構築することが可能です。

CLOSING

結びにかえて

セキュリティチェックシートの項目を管理することは、組織統制として一定の役割を果たします。しかし、書類上の手続きを満たすことと、実稼働するシステムが機械的な攻撃試行に耐えうる状態にあることは、技術的に別個の課題です。

監視員の頭数を増やすことでも、分厚い指摘報告書を積み上げることでもなく、「侵入するためのポートを閉じ、エッジとインフラで不要な通信を物理・論理遮断し、他者データを参照できないよう認可コードを整え、それをCI/CDで機械的に検査し続けること」。

ARCHECOは、手続きの形式論にとどまらず、「実稼働するコードとインフラそのものを堅牢化するエンジニアリング」を通じて、事業の持続可能な安全基盤を構築します。

無料の脆弱性診断の相談

いまのシステムについて、外から届く入口の数、クラウドの構成、チェックシートの要件を伺い、どこから模擬攻撃を始めるかを無料で見立てます。製品の提案ではなく、先に確かめるべきことと、費用を動かす条件を具体的にお返しします。

サムネイル_お問い合わせ
CONTACT

※弊社のリソース状況によってはお受け出来ないことがございます。

GET IN TOUCH

脆弱性診断のご相談はこちらから。いまどの段階か（診断を受けた直後／チェックシートの回答中／事故のあと／構築前）と、対象のシステム数とクラウド（AWS・GCPなど）を一言添えていただければ、初回から具体的な話ができます。他社の診断レポートがあれば、そのままお持ちください。

CONTACT

VIEW OTHER SERVICES