このサイトが勧める公開方法は、Vercelのようなサービスを使ったWeb展開です。エージェントに頼めば、コードを1行も書けなくても、本格的なWebアプリを短期間で公開できます。
ここで見落としやすいことが1つあります。「公開する」とは、世界中の誰からでもアクセスできる状態にする、ということでもあります。 この記事から始まる一連の記事は、その「公開した日から始まる話」を扱います。
これまでのセキュリティ記事との違い
このカテゴリには、すでに2本の記事があります。
どちらも、エージェントを使って作業している最中の安全の話です。コマンドを実行していいか確認する仕組み、手元の秘密情報が会話のログに残ってしまう事故。いわば「作っている間」の話です。
この記事から始まるシリーズは、「作って、公開したあとのアプリそのもの」の安全を扱います。誰かに壊されないか、勝手にデータを見られないか、悪用されて高額な請求が来ないか。作業中の安全とは、また別の話です。
なぜ非エンジニアほど危ういのか
先に断っておくと、エンジニアが書いたコードでも穴はできます。 セキュリティの不備は、経験年数だけでは防ぎきれません。プロが作ったサービスでも、あとから脆弱性が見つかることは珍しくありません。
ただし、非エンジニアが自分でアプリを公開する場合には、もう一段別の危うさが加わります。
「動く」ことと「安全である」ことは、まったく別の軸だからです。
画面が思ったとおりに動いて、ボタンを押したら期待した結果が返ってくる。ここまで確認できれば「完成した」と感じます。ですが、その確認作業では、「悪意を持った人が、想定外の使い方をしたらどうなるか」は一切試されていません。動作確認と安全確認は、見ている場所がそもそも違います。
エージェントは頼めば何でも作ってくれますが、「これを公開して大丈夫か」を自分から警告してくれるとは限りません。 頼まれた機能を作ることには長けていても、頼まれていない観点まで自発的に守ってくれるとは限らない、という前提で付き合う必要があります。
それでも、実装そのものはエージェントに頼める
ここまで読むと、「知らないことばかりで、どうすればいいのか」と不安になるかもしれません。安心してほしいのは、この先の記事で紹介する対策のほとんどは、内容を知ってさえいれば、実装そのものはエージェントに頼めるということです。
読者に求められているのは、穴を自分でふさぐ技術ではなく、「こういう種類の穴がある」と知っていて、具体的に名前を挙げて点検を頼むことです。「XSS対策はされていますか」「このAPIにレート制限はかかっていますか」と、名前を挙げて聞けば、たいていのエージェントは点検し、必要なら直してくれます。名前を知らなければ、そもそも聞くことができません。この記事群は、その「聞くための語彙」を揃えるためのものです。
完全に守ることはできない、という前提
最初に心構えとして持っておきたいのが、「100%安全」は存在しないということです。目指すのは、ゼロにすることではなく、壊されたときの被害を小さくすることです。
考え方の土台になる言葉を2つ、簡単に紹介します。
- 多層防御（defense in depth）：1つの対策だけに頼らず、複数の防御を重ねる考え方。1つ抜けても、次の層で止まるようにしておく
- 最小権限の原則（principle of least privilege）：必要な人・必要なプログラムにだけ、必要な分だけの権限を与える考え方。「念のため全部許可」は、被害が起きたときの範囲を広げます
どちらも、エージェントに「全部許可」を与えることの怖さと同じ発想です。作業中の安全でも、公開後の安全でも、根っこにある考え方は同じです。
何を守るのか——3つの観点
セキュリティの話は、漠然と「怖い」で終わりがちです。もう少し具体的に、何が損なわれると困るのかを3つに分けておくと、以降の記事が読みやすくなります。
| 観点 | 意味 | 損なわれると |
|---|---|---|
| 機密性（confidentiality） | 見てよい人だけが見られる状態 | 他人の個人情報やAPIキーが、見えるはずのない人に見られる |
| 完全性（integrity） | データが勝手に書き換えられない状態 | 価格やユーザーの投稿が、意図せず改ざんされる |
| 可用性（availability） | 使いたいときに使える状態 | サービスが止まる、遅すぎて使い物にならない |
この3つはセキュリティの世界で古くから使われている整理で、CIA（Confidentiality, Integrity, Availabilityの頭文字）と呼ばれることもあります。以降の記事で扱う個別のリスク（クロスサイトスクリプティング、認証の不備、DDoSなど）は、たいていこの3つのどれかを狙っています。どれを脅かす話なのかを意識すると、対策の優先順位も付けやすくなります。
この先に書く記事
具体的にどんなリスクがあり、何から手を付ければいいかは、Webアプリの主要セキュリティリスク一覧にまとめました。まずはそちらで全体像をつかんでから、気になるリスクの個別記事に進むのがお勧めです。