1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IPAの注意喚起を受けて、IaCから外部公開の入口を一覧にする手順

1
Last updated at Posted at 2026-10-14

自社やクライアントのシステムで、外部に公開している入口を点検したい皆様へ。

IPA(情報処理推進機構)は2026年10月9日に「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」を公開しました。公表された事例の傾向として、IPAは「外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっていることがうかがえます」と書いています。速やかに行うべき点検の最初に挙がっているのは、次の項目です。

自組織が独自に構築・運用している外部公開アプリケーションやサービスがあるかどうかを確認してください。

不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について(IPA)
https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html

注意喚起の宛先は、大量の情報や機微な情報を扱う事業者の経営者ですが、実際に点検の手を動かすのは、システムを管理している担当の方です。

CloudFormationやAWS SAM、TerraformなどのIaC(Infrastructure as Code)でクラウドを管理しているなら、この確認に使える情報は、IaCのファイルの中にあります。ただ、テンプレートが長くなるほど、どのリソースがインターネットから直接リクエストを受けるのかを、目で見て探すのは手間がかかります。

この記事では、Claude CodeにIaCを読ませて構成図を作り、その構成図をもとに、インターネットからの入口、つながっている外部のシステム、個人情報を置く場所の3つを一覧にする手順をご紹介します。ここでいう入口は、API GatewayやCloudFrontのように、インターネットから直接リクエストを受けるリソースを指します。最後に、入口ごとの認証の設定を、Claude Codeに元のファイルで確かめてもらいます。

使うのは、私たちが運営しているIceShore(アイスショア)です。IceShoreとは、システムごとのユースケースの整理をお使いのAIに促し、構成図を自動生成する構成管理プラットフォームです。お使いのAIがIaCを読み、誰が・どの経路で・何をするか(ユースケース)まで構成図に書きます。点検の質問には、その構成図を読んだAIが答えます。Claude CodeとはMCP(Model Context Protocol)でつながります。

構成図で確かめられる点検の項目

IPAの注意喚起は、速やかに行うべき点検を3つの見出しに分けています。

  • 外部に公開しているアプリケーションの精査。外部公開アプリケーションやサービスがあるかの確認、直近のログの確認、未適用の脆弱性対応パッチの確認が並んでいます。
  • 自組織が利用している外部サービスの洗い出し。外部サービスの洗い出しと、サービス単位のログとアカウントの確認が並んでいます。
  • 保有データの再点検。保有する情報資産を正確に把握し、必要最小限にすることが求められています。

このうち、IaCから起こした構成図で確かめられるのは、1つ目の見出しの最初の項目、外部公開アプリケーションやサービスがあるかどうかの確認です。あわせて、IaCに書かれている範囲で、外部のシステムとのつながりと、個人情報を置く場所も一覧にできます。個人情報を置く場所の一覧は、3つ目の見出しにある「自らが保有する情報資産を正確に把握し」の手がかりになります。

構成図で分かるのは、入口がどこにあるかまでです。その入口に認証が設定されているかは、元のファイルと稼働中の環境で確かめます。

使うリポジトリ

GitHubで公開されている aws-samples/serverless-coffee(MIT-0)を使います。READMEによると、AWS re:Invent 2021 で初めて展示されたコーヒーバーのシステム「Serverlesspresso」のコードで、AWSのワークショップの教材にもなっています。READMEがデプロイを指示しているIaCは、AWS SAMの 00-baseCore/template.yaml(基盤)と 01-appCore/template.yaml(本体)の2つです。

git clone https://github.com/aws-samples/serverless-coffee.git
cd serverless-coffee

AWSへのデプロイは要りません。読むのはリポジトリの中のファイルだけです。公開されているリポジトリなので、同じ手順を手元で試せます。ただ、AIの答えは実行のたびに少し変わり、表の形や数え方が、この記事と同じにならないことがあります。

預けるデータの扱い

ご自身やクライアントのリポジトリで試すと、IaCをIceShoreに預けることになります。それ自体が、外部サービスを1つ使うことです。試す前に、次の扱いをご確認ください。クライアントから預かっているIaCは、委託元の承諾が要る場合があります。

  • IceShoreに保存されるのは、ADL(Architecture Description Language)という形式で書いた構成図と、そこから参照するIaCのファイルです。今回送られたのは、2つのテンプレートでした。後で出てくるAPI定義のファイルは送られておらず、手元で読んでいます。保管場所はAWSの東京リージョンです。
  • アクセスキー、秘密鍵、接続文字列、パスワードやトークンに見える値は、保存の前にマスク(***MASKED*** に置き換え)されます。決まった形を探して置き換える仕組みなので、すべてを拾える保証はありません。秘密の値は、IaCのファイルに直接書かず、Secrets Managerや環境変数に置いてください。
  • Terraformは、.tf のファイルをそのまま渡すより、terraform plan -out=tfplan.bin のあと terraform show -json tfplan.bin で書き出した結果を渡すことをおすすめします。モジュールや for_each count が展開されるからです。ただし、TerraformのJSONの出力は、sensitiveの値をマスクしません。planの結果にもstateの値や変数の値が入るので、渡す前に秘密の値が含まれていないかをご確認ください。
  • 非公開のままであれば、構成図を見られるのは、そのワークスペースのメンバーです。当社の従業者が見るのは、サポートの依頼への対応など、プライバシーステートメントに定めた場合に限ります。
  • 画面で構成図やワークスペースを削除すると見えなくなりますが、保管場所からは消えません。保管場所からの消去は、ワークスペースのオーナー(有料プランでは契約者)が legal@iceshore.ai へ請求できます。詳しくはプライバシーステートメントの「保存期間と削除」をご覧ください。

プライバシーステートメント
https://legal.iceshore.ai/ja/privacy_statement.html

Claude CodeにIceShoreをつなぐ

ターミナルで次の1行を実行します。

claude mcp add -s user iceshore --transport http https://mcp.iceshore.ai/mcp

iceshore の部分は、Claude Codeがこの接続を呼ぶときの名前です。-s user は利用者全体の設定を書き換えます。案件ごとに作業環境を分ける規程があるなら、プロジェクト単位のスコープをご利用ください。試し終えたら、claude mcp remove iceshore -s user で外せます。

構成図を登録するには、IceShoreのアカウント(無料)が要ります。ターミナルで次のコマンドを実行すると、ブラウザでIceShoreのログイン画面が開きます。アカウントが無ければ、その画面から無料で登録できます。

claude mcp login iceshore

接続を許可したら、ログインは完了です。起動中のClaude Codeでは、/mcp から iceshore を選んでログインすることもできます。ログインが反映されないときは、Claude Codeを起動し直してください。

リポジトリを登録する

clone したディレクトリでClaude Codeを起動し、次のように頼みます。

このリポジトリをIceShoreに登録して

Claude Codeは、READMEとテンプレートを読み、登録する内容の要約を示して、IceShoreに書き込む前に確認を求めます。今回の要約は、READMEがデプロイを指示している2つのテンプレートを対象にし、起点になる人やシステム(アクター)を4つ、ユースケースを8つとする内容でした。利用者の人数のように、コードに書かれていない値は、AIの見積もりであることも書き添えられていました。構成図の図に出る rps などの数値も、同じく見積もりです。

登録のとき、Claude Codeはリポジトリの中に iceshore/ と .iceshore/ を作り、構成図の元データを置きます。Claude Codeの設定によっては、IceShoreへの登録の確認とは別に、ファイルを作る許可も求められます。リポジトリに含めたくない場合は、コミットの前に外してください。

確認に「はい」と答えると、構成図が個人のワークスペースに登録されます。今回は、要約が出るまでに約5分、登録が終わるまでにさらに約5分かかりました。

画面で構成図を確かめる

登録された構成図は、IceShoreの画面で開けます。図を拡大すると、来場者・バリスタ・店舗管理者などのアクターから、入口のリソースへ線が引かれています。

C-0075-01-diagram-zoom.jpg

入口を一覧にする前に、ここで、登録した範囲が意図どおりかを確かめておきます。

入口・外部のシステム・個人情報の保存先を一覧にする

Claude Codeに、次のように頼みます。

IceShoreに登録したServerlesspressoの構成図で、インターネットからの入口を一覧にして。あわせて、外部のシステムと、個人情報や機密情報を保存している場所も一覧にして。

Claude CodeはIceShoreから構成図を読み、3つの表で答えました。入口の表を要約すると、次のとおりです(行と列をまとめています)。

# 入口(リソース) 使う人 ユースケース
1 Cognito ユーザープール(UserPool) 来場者 顧客の SMS サインイン
2 Cognito ID プール(IdentityPool) 来場者 リアルタイム通知の購読
3 Validator API(RESTApiValidatorService) 来場者・バリスタ QR コードの表示・読み取り
4 Order Manager API(RESTApiForOrderManager) 来場者・バリスタ 注文の送信・対応
5 Config API(RESTApiConfigService) 店舗管理者 店舗設定の管理
6 CloudFront(JourneyCloudFront) 店舗管理者 注文ジャーニーの閲覧

IaCには、入口ごとに誰が何のために使うかまでは書かれていません。この表の「使う人」と「ユースケース」の2列は、AIがIaCやコードの名前から推し量って構成図に書いたものです。入口ごとに、誰のための入口かが分かると、公開してよい入口かどうかを判断しやすくなります。

外部のシステムとして挙がったのは、サインイン用のコードを送るSMSの配信(コードではAmazon SNS)の1つでした。個人情報や機密情報の保存先には、CognitoのユーザープールとDynamoDBのテーブル4つ、S3のバケット、CloudWatch Logsのロググループの、7か所が挙がりました。

答えの中で、Claude Codeは構成図と実態のずれにも触れていました(太字などの装飾を外して引用しています)。

構成図と実態がずれている可能性:IoT Core(ServerlesspressoRealtime)は構成図では内部扱い(internet: false)です。ただ実際には、各アプリが MQTT over WebSocket でインターネットから直接つないでいます。入口として扱うのが妥当です。

internet: false は、構成図の中で、インターネットから入る経路ではないことを表す項目です。アプリ本体はこのリポジトリに含まれていませんが、IDプールのロールにIoT Coreへの接続の権限が付いていることは、テンプレートで確かめられます。AIがIaCから下書きした構成図なので、入口の見落としが起こりえます。一覧に出たものを確かめるのと同時に、一覧に出ていない入口がないかも、元のIaCで確かめます。

入口ごとの認証を、元のファイルで確かめる

続けて、次のように頼みます。

それぞれの入口に認証が設定されているかを、このリポジトリの元のテンプレートとAPI定義のファイルで確かめて。

Order Manager APIとConfig APIは、APIの定義を別のファイル(backends/ の下の RestAPIs/api.yaml)から取り込んでいて、テンプレートだけでは認証の設定が分かりません。Claude Codeは、テンプレートに加えて、この2つのAPI定義と、認可を判定しているコードを開いて答えました。答えの結論は次のとおりです。

認証(ログインしているか)は、API Gateway の大半のエンドポイントで設定されていました。認証が無いのは次の3か所です。

  • Config API の GET /config
  • Cognito ID プールのゲスト利用
  • CloudFront

認証が無いことが、そのまま誤りとは限りません。ログインの前に読む設定や、誰でも見られる前提のページのように、公開する意図があるものも含まれます。公開する意図があるかどうかを、入口ごとに確かめます。

認証(ログインしているか)とは別に、認可(その操作をしてよい人か)にも、Claude Codeは触れていました。管理者かどうかを確かめているのは、QRコードを表示するエンドポイント(GET /qr-code)だけだ、という指摘です。認可はAPIの定義ではなく、関数やワークフローのコードの中で判定されることが多いので、構成図からは分かりません。

ログインできる人の範囲も、あわせてご確認ください。このサンプルのように、誰でもサインアップでき、承認も自動であれば、「ログインしている」は役割の確認にはなりません。

なお、ここで挙げた点は、この手順で何が分かるかの例として載せたもので、サンプルの良し悪しを評価するものではありません。

点検の記録にまとめる

答えには、根拠のファイルと行番号も示されていました。私たちも元のファイルを開いて確かめ、入口ごとに次の表にまとめました。上司やクライアントに報告するときは、この形が使えます。

入口 認証の設定(ファイルで確かめた結果) 根拠のファイル
Cognito ユーザープール カスタム認証でSMSのワンタイムコードを送る設定。サインアップは誰でもでき、承認は自動 00-baseCore/template.yaml、00-baseCore/cognito-triggers/pre-sign-up.js
Cognito ID プール ゲスト(未ログイン)の利用を許可 00-baseCore/template.yaml(AllowUnauthenticatedIdentities: true)
IoT Core(構成図では入口として扱われていない) ID プールの一時的な認証情報で接続。ゲスト(未ログイン)でも取得できる 00-baseCore/template.yaml(CognitoUnAuthorizedRole)
Validator API Cognitoのオーソライザー 01-appCore/template.yaml
Order Manager API OPTIONS(CORSの事前確認)を除くすべてのメソッドにCognitoの指定 backends/5-order-manager/RestAPIs/api.yaml
Config API PUT /store と GET /admin-config にCognitoの指定。GET /config には指定なし backends/2-config-service/RestAPIs/api.yaml
CloudFront 署名付きURLなどのアクセスの制限なし。S3 へは CloudFront 経由に限定(OAI) 01-appCore/template.yaml

ファイルで分かるのは、書かれた設定までです。デプロイされた環境が同じ設定で動いているかは、AWSのコンソールやAWS Configなどで確かめます。構成図はワークスペースに残るので、次の点検でも同じ構成図から始められます。

構成図では分からないこと

この方法で一覧にできるのは、IaCに書かれた範囲です。次のものは、構成図からは分かりません。

  • IaCの外にあるものは、構成図に出ません。コンソールで手で作ったリソース、SaaS、VPN機器、部署が個別に契約したクラウドがこれにあたります。
  • IceShoreは構成を記述するもので、稼働中の環境を見に行きません。ログ、パッチの適用状況、アカウントの点検は、それぞれの環境で行います。
  • 構成図の中身は、AIがIaCから下書きしたものです。今回も、IoT Coreが入口として扱われておらず、API定義にあるエンドポイントの一部も構成図に載っていませんでした。構成図の説明や分類は、元のファイルで確かめてから点検の記録に使ってください。

IPAは外部サービスについて、次のように書いています。

自組織が利用している外部サービスをすべて洗い出してください。
クラウドサービス、VPNサービス等様々な分類があること、また組織全体、部署単位での利用がありうることを踏まえ、できる限り網羅的に把握してください。

IaCを読むだけでは、この網羅的な洗い出しはできません。構成図の一覧は、IaCで管理している部分の一覧として、契約の一覧や各部署への確認など、別の手段と組み合わせてご利用ください。

また、異常が見つかったときの対応について、IPAは次のように書いています。

外部に公開しているアプリケーション、自組織が利用している外部サービスのいずれにおいても、異常なログやアカウントの発見があった場合は、速やかにセキュリティインシデントと判定し、インシデント対応を進めてください。情報漏えいの可能性を考慮し、専門のセキュリティベンダーに詳細調査を依頼することを強く推奨します。

構成図の一覧が役に立つのは、ログやアカウントを調べる前に、どの入口から確かめるかを決める場面です。

以上です。

なお、IceShoreは有償ですが(無料プランがあり、1人で使う範囲なら構成図の数に上限はありません)、構成図の記述に使うADLはオープンソースです。

IceShore
https://iceshore.ai/?utm_source=zenn&utm_medium=referral&utm_campaign=launch2610&utm_content=c-0075

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?