AI app security
AIで作ったアプリの、
公開前チェック
サイバー被害が激増しています。
AIで業務に合うアプリを自分たちで作れるようになった今、公開の前に一度確かめましょう。
Threats
公開したその日から、
狙われています。
24時間、自動で探される
攻撃は自動化されています。公開されたサーバーやアプリは、昼も夜も弱点を探され続けます。
攻撃にもAIが使われる
最近の報道では、攻撃にAIが悪用されている可能性が指摘されています。
中小企業も狙われる
大企業だけではありません。使っているサービスを経由して、中小の事業者も被害に遭っています。
こんな方へ
-
自分で作った方
アプリは動いたものの、公開してよいか迷っている方へ。
-
これから作る方
業務で使う前提で、気をつける点を先に知っておきたい方へ。
-
外注で作った方
納品されたアプリの設定を、自社では確かめきれない方へ。
Common holes
AIで作ったアプリに多い穴
AIは「動くもの」を作るのは得意ですが、公開してよい作りかどうかは、指示しないと確かめないことが多くあります。
- APIキーの直書き
- APIキーは、外部サービスを使うための認証情報です。動かすためにプログラムへ直接書き、そのまま公開すると、第三者に知られるおそれがあります。
- 設定ファイルの公開
- 「.env」などの設定ファイルには、パスワードなどが入ることがあります。公開するファイルから除き忘れると、中身が見えてしまいます。
- ログインなしの管理画面
- 管理機能が動いても、ログインを求める仕組みがなければ、URLを知る人が開けてしまいます。
- 外から見えるデータベース
- データベースは、アプリの情報を保存する場所です。接続を許す相手の設定が広すぎると、外から情報を見られるおそれがあります。
Before release
公開前に確認すること
APIキー・パスワードの置き場所
認証情報の保管先と、それを見られる人を確認します。公開するファイルに紛れ込んでいないかも調べます。
ログインと権限
利用者ごとに、見られる情報と操作できる範囲を確認します。必要な人に、必要な分だけを許す設定かを見ます。
データベースの公開設定
保存した情報を、誰が読めて、誰が書き換えられるかを確認します。
更新の当て忘れ
アプリやサーバーで使うソフトウェアに、適用していない修正プログラムがないかを確認します。
バックアップと戻し方
データの控えを取る頻度と保存先、止まったときに戻す手順を確認します。
通信の暗号化（SSL）
画面とサーバーの間でやり取りする情報が、暗号化される設定かを確認します。
持たなくていいデータ
本人確認書類の画像やパスワードなどを、必要以上に保存していないかを確認し、持つ必要があるかを見直します。
Infrastructure design
チェックだけでは、
足りません。
公開前のチェックは、多くのAI事業者も行う基本の対応です。本当に差が出るのは、アプリの規模と扱うデータに合わせて、インフラ（アプリを動かすサーバーやクラウドの構成）を選び、設計できるかです。
-
小さく始める
社内の数人で使い、公開してよい情報を中心に扱うアプリ。
必要な機能と管理の手間を見極め、小さな構成から始めます。
-
しっかり守る
社外の人も使い、顧客情報を扱うアプリ。
利用者ごとに閲覧・編集できる情報を整理し、通信と保存データの暗号化、バックアップの保存先・頻度まで設計します。
-
止めない・漏らさない
業務の要になり、多くの個人情報を扱うアプリ。
管理用の入口と権限を絞り、複数台・複数拠点への冗長化、通信・保存データ・バックアップの暗号化、障害時の切り替えと復元手順まで設計します。
Our setup
自社では、
こんな構成で動かしています。
言葉で「できます」と書くのは簡単です。だから、自社のサーバー（AWS）で実際に動かしている構成をお見せします。
- 管理用の入口を開けない（SSM）
- サーバーに入るための入口（SSH）を外に開けず、鍵も配りません。誰が入れるかはAWSの権限設定で管理します。
- アプリの定期処理（cron）は本番に置かない
- アプリの定期処理は手元のMacから呼び出すだけにし、本番サーバーは届いたリクエストを処理するだけの受け身にしています。
- 呼び出し口を4重に絞る
- 接続元のIP制限・認証・POSTのみ許可・何度やり直しても同じ結果になる設計（冪等性）を組み合わせています。
- 権限は必要最小限
- 作業に必要な範囲だけ、操作やアクセスを許可しています。
- 変更の記録を残して公開
- Gitで変更履歴を管理し、何を変えたかが残る方法で公開・更新しています。
- 通信・保存データの暗号化と復元の備え
- SSLで通信を暗号化し、保存データとバックアップも暗号化したうえで毎日バックアップを取り、実際に復元できることを確認済みです。
Proposal
業務を支える設計：冗長化と暗号化を備えます。
1台構成では、その1台が止まるとアプリを使う業務も止まります。暗号化せずに保存した顧客情報は、漏れたときに内容を読まれるおそれがあります。公開前の設定確認に加え、冗長化（1台が止まっても別のサーバーが引き継ぐ構成）と暗号化を最初から設計に織り込みます。
- サーバーの冗長化複数台を複数拠点に配置し、障害時に処理を切り替える構成を提案します。
- データベースの分離と冗長化データベース（情報を保存・管理する仕組み）をアプリとは別のサーバーに分け、複数拠点で引き継げる構成を提案します。
- データの暗号化SSL（通信を暗号化する仕組み）に加え、ディスク（保存領域）・データベース・バックアップの暗号化を提案します。
- 鍵と権限の管理暗号を解く鍵の保管先と使える人を定め、データに触れる権限を必要最小限に絞る設計を提案します。
すべてを最初から導入する必要はなく、顧客情報を扱うアプリや業務の要になるアプリから、規模とデータに合わせて段階的に整えます。
Proposal
次世代のcron：手元のPCを起点に、ルーティンを回す。
アプリの定期処理を本番サーバーに持たせず、手元のPCが「いつ実行するか」を決めて呼び出します。本番サーバーは受け身になり、守るべき入口が減ります。手元のPCではAIエージェントも動かせるので、毎日のルーティンをAIに任せる仕組みとも相性のよい構成です。
向いているのは、日次・週次の処理や小〜中規模のサービスです。分単位の実行や、24時間止められないシステムでは、クラウドの定期実行サービスを組み合わせます。
設計の考え方は、noteで詳しく公開しています。AWS推奨のSession Manager運用。その先で、本番サーバーからcronもなくしてみた
What we do
頼めること
進め方
- 01
初回相談
無料の初回相談で、アプリの用途と気になる点を伺います。
- 02
アプリの共有
画面共有などで、相談して決めた範囲を見せていただきます。
- 03
結果の報告
確認結果を、直す優先順位とともにお伝えします。
- 04
修正
自社で直すか、修正を任せるかを選べます。
- 05
公開
修正後の状態を確認し、公開へ進みます。
- 06
運用
公開後も、必要な分だけ運用を依頼できます。
Engineer
担当するのは、
現役のWebエンジニアです。
DDDynamis代表の川端康平です。AIで社員がアプリを作れるように育てる側と、そのアプリを本番で動かす側の、両方を担当します。
確認結果は、専門用語だけで済ませず、何をどう見直すかが分かる言葉でお伝えします。
FAQ
よくある質問
Q外注先が作ったアプリでも相談できますか？
Aはい。外注先が作ったアプリも対象です。
Qすでに公開しているアプリでも相談できますか？
Aはい。公開済みのアプリについても、設定の確認や見直しをご相談いただけます。
QどのAIで作ったものでも相談できますか？
Aはい。Claude Code・ChatGPTなど、使ったAIは問いません。
Qコードや画面を見せるのが不安です。
A最初からすべてを見せていただく必要はありません。共有する範囲と方法を相談して決め、その範囲で確認できることをお伝えします。
Q費用はどう決まりますか？
A初回相談は無料です。お話を伺ったうえで、必要な作業の範囲と費用をご案内します。
