NeuralOS
GuideAdvanced

Enterprise級の防御 · あなたのアプリを「攻めにくい家」にする8つのレイヤー

前の記事では、公開前に必須の3つの鍵を紹介した。これはその次のレベル、本気のプロダクトが使う防御だ。まず、不快だが解放的な真実から始めよう。何も「完全無敵」ではない。Google、Stripe、銀行 — すべて攻撃されうる。本当の目標は無敵になることではない。攻撃するのが高くつき、面倒すぎて、攻撃者があきらめてもっと簡単な獲物へ行くようにすること、そして何かが起きたときに被害を封じ込めて、一つの失敗が大惨事にならないようにすることだ。それは家と同じ。盗まれない家は存在しない。存在するのは、柵とアラームと犬とカメラがある家 — 泥棒が見て、手間を計算し、隣の家へ行く家だ。それが目標、攻めにくい家になること。ここにそれを実現する8つのレイヤーがある。シンプルな言葉で、それぞれ例えとAIに頼むためのプロンプト付き。

Jun 20, 202615 min
これは誰のため?
AIで本気で何かを作り、本物のセキュリティが欲しい人のため — SaaS、多くのユーザーを持つアプリ、お金や機微なデータを扱うもの。プログラミングは不要だが、シリーズの中で最も上級の記事だ。まだ始めたばかりなら、まず[3つの基本の鍵](/recursos/protege-tu-app-rls-cors-headers)をやろう。本気になったら、ここに戻ってくればいい。

不快な(そして解放的な)真実

何も「完全無敵」ではない。そう言わない人はあなたに嘘をついている。Google、Stripe、銀行:すべて攻撃されうる。では、セキュリティに何の意味があるのか? 本当の目標は無敵になることではない — 攻撃するのが高くつき、面倒すぎて、攻撃者があきらめ、もっと簡単な獲物へ行くようにすることだ。そして何かが起きたときに被害を封じ込めて、一つの失敗が大惨事にならないようにすることだ。

こう想像しよう · 攻めにくい家
盗まれない家は存在しない。存在するのは、柵とアラームと犬とカメラがある家 — 泥棒が見て、手間を計算し、隣の家へ行く家だ。それがまさにセキュリティの目標だ。無敵になることではなく、攻めにくい家になることだ。
鍵となる概念:多層防御
大企業が安全なのは魔法のトリックのおかげではない。安全なのは、たくさんの壁を、次々に重ねて置くからだ。攻撃者が最初の壁を越えても、二番目にぶつかり、三番目にぶつかる。これを「多層防御」と呼ぶ。ルール:一つの失敗だけで侵入できてはいけない。だから8つのレイヤーであって、一つではないのだ。

レイヤー1 · ドア(誰が、何に入れるか)

人がよく混同する2つのこと:認証(authentication)は「あなたは名乗る通りの人物か?」(ログイン)、認可(authorization)は「あなたはこの具体的な操作をする権限があるか?」(このユーザーはこのデータを見られるか?)だ。黄金律:デフォルトで拒否。明示的に開けない限りすべては閉じている — その逆は決してない。ほとんどの漏洩は、誰かが何かを「デフォルトで開いたまま」にして閉じるのを忘れたために起きる。

AIに頼もう · レイヤー1texto
「デフォルトで拒否」のルールでバックエンドの認証と認可を守りたい。各エンドポイントは閉じた状態で生まれ、明示的な理由がある場合のみ開くべきだ。すべてに認証を要求するグローバルなガードを設定し、私が指定したものだけを公開としてマークできるようにして。認可については、ログインだけでなくアクションごとに権限を検証して。何をしたかシンプルなステップで説明して。

レイヤー2 · 隣人同士の壁(誰も他人のデータを見られないように)

ユーザーが多いなら最重要
アプリが同じデータベースに多くのユーザーを持つなら、致命的なリスクは、バグによって一人が他人のデータを見てしまうことだ。この保護はRow Level Security(RLS)と呼ばれる。データベース自身が、行ごとに「あなたは自分のものしか見られない」を強制する — プログラマー(やAI)がコード内でフィルタリングを忘れても。うっかりミスに耐える壁だ。これは本気のプロダクトとアマチュアの違いだ。

このレイヤーはまさに前のガイドで見たもの(鍵1)だ。ここではそれをアーキテクチャのルールに引き上げる。マルチユーザーのプロダクトでは、RLSはオプションではなく、土台だ。

AIに頼もう · レイヤー2texto
私のアプリはマルチユーザーだ(同じデータベースに多くの顧客がいる)。Row Level Securityで完全な分離を確保して:ユーザーデータを持つ全てのテーブルでRLSを有効にし、各人が自分のものだけにアクセスできることを保証するポリシーを付けて。コードにバグがあってもデータベースが強制するようにしたい。パフォーマンスのために(SELECT auth.uid())を使い、authenticatedロールに制限して。SQLをくれて、あるユーザーが他人のデータを見られないことをどう検証するか説明して。

レイヤー3 · 数えるドアマン(誰にも氾濫させないように)

こう想像しよう
レート制限(rate limiting)は数えるドアマンだ:各ユーザーやIPには1分あたりのリクエスト上限がある。攻撃者があなたを倒そうと毎秒10,000リクエストを投げても、ドアマンは100番目で遮断して締め出す — サーバーは残りに気づきもしない。氾濫攻撃に対するあなたのシートベルトだ。
AIに頼もう · レイヤー3texto
バックエンドにレート制限を追加して:ユーザーごと・IPごとに1分あたりのリクエスト上限を設け、機微なエンドポイント(ログイン、登録、AIを呼ぶもの)ではより厳しくして。上限を超えたら、サーバーを倒さずに明確なエラー(429)で応答して。最初に推奨する上限値と、その調整方法を教えて。

レイヤー4 · 外側の盾(攻撃がドアにすら届かないように)

悪意あるリクエストがサーバーに触れる前に、外側の盾を通る — Cloudflareが標準だ。その盾は大規模な攻撃(DDoS:数千台のマシンが同時に攻撃してくる)を吸収し、既知のボットをふるいにかけ、攻撃パターンをブロックする。あなたのサーバーはその後ろに隠れ、ドアを直接さらさない。これが最前線、大手が使うものだ。

AIに頼もう · レイヤー4texto
アプリの前に外側の盾(CloudflareのようなWAF/CDN)を置きたい。シンプルなステップで案内して:ドメインをCloudflareを経由させること、DDoS保護とアプリケーションファイアウォールを有効にすること、そして誰も直接攻撃できないようにオリジンサーバーを隠すこと。最初に有効にすべき設定と、どれが無料かを教えて。

レイヤー5 · 鍵を金庫に(秘密が漏れないように)

あなたの最大の悪夢、そして当然だ
コードに漏れたAPIキーは、家の鍵をドアに貼ったまま置いておくようなものだ。ルール:(1)秘密は決してコードやgitに住まわせない — 別の金庫(vault)に住まわせ、環境変数として注入する。(2)ユーザーの鍵は暗号化して保存し、ユーザーごとに別の鍵を使う。そうすればデータベースを盗まれても誰の鍵も読めない。(3)自動検出ツール(gitleaks)が各コミットの前に、どの秘密も誤って流出しないか確認する — 鍵をアップロードしようとすると、止めてくれる。
AIに頼もう · レイヤー5texto
私の秘密(APIキー、パスワード、トークン)を守って。1) コードとgitから取り出す:環境変数に置き、.envを無視する.gitignoreを作って。2) ユーザーの鍵を保存するなら、ユーザーごとの鍵でデータベース内で暗号化して。3) gitleaksを各コミット前のフックとして設定し、誤って秘密をアップロードしようとしたら止めてくれるようにして。各ステップをシンプルに説明して。

レイヤー6 · 入ってくるものすべてを疑う

ユーザーが送ってくるものを決して信じてはいけない。バックエンドに届く各データは、何かに触れる前に厳格なスキーマで検証する。これで典型的な攻撃をブロックできる:SQLインジェクション(攻撃者がフォームにコマンドを仕込んでデータベースを盗む)、プロンプトインジェクション(ユーザーがあなたのAIを操作してルールを飛び越えさせる)、そしてシステムを壊す不正なデータだ。ルール:各境界で検証する。外部のものはすべて、証明されるまで疑わしい。

AIに頼もう · レイヤー6texto
バックエンドの全ての入力を、各エンドポイントで処理前に厳格なスキーマ(Zodか同等のもの)で検証して。スキーマを満たさないものは拒否して。特にSQLインジェクション、AIへのプロンプトインジェクション、不正なデータから守って。各境界に適用するパターンと、私のエンドポイントの一つでの例をくれ。

レイヤー7 · ユーザーにお金を出血させられないように

AI製品の特有のリスク
悪意あるユーザー(あるいは単なるバグ)が、高価なAI呼び出しを何千回も行ってあなたのお金を燃やすかもしれない。保護策:ユーザーごとの予算 — 各人に1日の支出上限があり、達したら遮断する。さらに、消費を計測するシステムが異常な支出をする者を検知し、あなたに損害を与える前に止める。メーターは会計だけではない:盾だ。
AIに頼もう · レイヤー7texto
私のアプリはAI(使用量に応じてお金がかかる)を使う。ユーザーにクレジットを出血させられないように守って:1) 各ユーザーにAI使用の1日の予算/上限を設け、達したら明確なメッセージで遮断して。2) 異常な振る舞いを検知するためにユーザーごとの消費を記録して。3) 誰かが支出を跳ね上げたら私に知らせて。通常のユーザーに影響しないように上限をどう定めるか説明して。

レイヤー8 · すべてにカメラを(監査)

見えないものは守れない。重要なアクションはすべて、誰にも消せない不変のログに記録される(誰が、何を、いつ)。何か変なことが起きたら、録画がある。そしてアラートシステムが、後からではなくその最中に知らせてくれる。これがあなたを安眠させるものだ:誰かが何かを試みたら、ライブで見える。

AIに頼もう · レイヤー8texto
アプリに監査と可観測性を追加して:1) 重要なアクション(ログイン、データ変更、支払い)で誰が何をいつしたかを記録する不変のログを、消したり編集したりできないようにして。2) 疑わしいことが起きたら(多くのログイン失敗、異常な支出、ピーク時のエラー)リアルタイムで知らせるアラート。まず記録すべきイベントと、アラートの受け取り方を教えて。

すべてを要約する真実

高い壁ではなく、たくさんの壁
大企業が安全なのは魔法のトリックのおかげではない:これらのレイヤーを、すべて、規律を持って、一つも飛ばさずに適用しているのだ。セキュリティは高い壁ではない — たくさんの壁だ。攻撃者が一つを越えても、次にぶつかるように。多層防御。一つの失敗だけで侵入できてはいけない。
セキュリティは最後ではなく、土台から築く
最も高くつく間違い:セキュリティを「最後に、時間があれば」に回すこと。最後に付け足すものは決して機能しない。土台から築いたものは、機能する。だからこれらのレイヤーは追加物ではない — 基盤だ。AIには、ローンチ間近になってからではなく、プロジェクトの初日から頼もう。

マスタープロンプト · 8つのレイヤーを一度に

本気のプロジェクトを立ち上げるときに全部まとめて頼みたいなら、このプロンプトは8つのレイヤーを要約し、AIが土台から考慮できるようにする:

本気のプロジェクトの最初にAIに貼り付けようtexto
このバックエンドを、初日からenterprise級のセキュリティで、「多層防御」(たくさんのレイヤー)を使って構築しよう。作るものすべてでこの8つのレイヤーを考慮し、どれが欠けているか私に思い出させて:

1. AUTH:「デフォルトで拒否」の認証+認可(明示的に開けるものを除きすべて閉じる)。
2. 分離:全テーブルでRow Level Security(各ユーザーは自分のものだけを見る、データベースが強制)。
3. レート制限:ユーザー/IPごとのリクエスト上限、機微なエンドポイントではより厳しく。
4. 外側の盾:前面にWAF/CDN(Cloudflare)、DDoS保護付き、オリジンは隠す。
5. 秘密:コード/gitに鍵を置かない;vault + 環境変数;ユーザーの鍵は暗号化;各コミット前にgitleaks。
6. 検証:全入力を各境界で厳格なスキーマ(Zod)で検証;SQLインジェクションとプロンプトインジェクションへの保護。
7. コストガードレール:自動遮断付きのユーザーごとAI予算;異常消費の検知。
8. 監査:不変のログ(誰が/何を/いつ)+ リアルタイムアラート。

まず、私のプロジェクトにどれが該当し、どの順で実装するかを教えて。まだ必要ないものへの過剰設計はしないで。
NeuralOSでは、これらのレイヤーが土台だ
NeuralOSではこの8つのレイヤーは、あなたが付け足す追加物ではない:アプリが構築される基盤の一部だ — RLS、暗号化された秘密、レート制限、検証、コスト上限が初日から。うっかりで安全でないものをローンチできないようにするのが狙いだ。岩の上に建てるか、砂の上に建てるかの違いだ。
アプリを守ろう · 3つの基本の鍵(ここから始めよう)
この記事が大きすぎたなら、必須の3つの保護が最初のステップだ。
C-A-Rプロトコル · 公開前にセキュリティを監査しよう
この8つのレイヤーを、AIのビルダーモードがいつも忘れる監査フェーズに入れよう。
#セキュリティ#enterprise#backend#多層防御
Ready to build?

Start building in
under 3 minutes

Join 4,200+ builders. No credit card. Build your first app with AI in minutes.