1. 審査票を開いた
決済サービスを導入しようとしたとき、セキュリティガバナンスのアセスメントが求められた。企業がオンライン決済を扱うにあたって、どのようなセキュリティ体制を持っているかを確認するためのものだ。
大企業であれば、専任のセキュリティチームが数週間かけて回答するような内容が並ぶ。質問票を開いて、身構えた。
だが、答えはほぼすべて同じだった。
2. 聞かれたこと、答えたこと
アセスメントが確認してくるのは、おおよそこのような内容だ。
2段階認証を設けているか
ペネトレーションテストを定期的に実施しているか
脆弱性モニタリングを行っているか
センシティブなデータを公開されている場所に置いていないか
アクセス権限の管理はどうなっているか
答えはすべて「GitHubです」だった。
2段階認証はGitHubのデフォルト設定で有効にしている。ペネトレーションテストはGitHub自身が世界規模で継続的に実施している。脆弱性モニタリングはDependabotが自動で動いている。センシティブなデータはそもそもサーバーに存在しない。アクセス権限はGitHubのリポジトリ設定で管理されている。
3. なぜこうなるのか
このプロダクトのインフラは、GitHubの上にしか存在しない。コードはGitHubに置かれ、配信はGitHub Pagesで行われ、自動処理はGitHub Actionsで動く。顧客の個人情報はサーバーには送られず、各自のデバイスの中にしかない。
つまり、攻撃者が狙うべき「自前のサーバー」が存在しない。漏洩しうる「預かったデータ」がない。侵入されうる「独自のインフラ」がない。
セキュリティリスクの多くは、何かを持つことから生まれる。データを持てばそれを守る必要が生まれる。サーバーを持てばそれを監視する必要が生まれる。持たなければ、守るものが最小になる。
4. 巨人の肩に乗る、という設計
GitHubは世界で1億人以上の開発者が使うプラットフォームだ。そのセキュリティ体制は、個人や小さなチームが自前で構築できるレベルをはるかに超えている。専任のセキュリティエンジニアが常時監視し、定期的に外部機関によるペネトレーションテストを受け、脆弱性が発見されれば即座に対応される。
GitHubの上に乗るということは、その体制をそのまま継承するということだ。ゼロコストで、世界水準のセキュリティガバナンスの傘の下に入る。
これは「巨人の肩に乗る」という古い表現がそのまま当てはまる。自分より大きなものの上に立つことで、自分だけでは届かない高さに立てる。セキュリティにおいては、その高さが審査の通過を意味する。
5. セキュリティは構築するものではなく、選ぶもの
かつてセキュリティは、構築するものだった。自前のサーバーにファイアウォールを設置し、侵入検知システムを導入し、ログを監視し、定期的に外部診断を受ける。それが「セキュリティ体制がある」ということだった。
だが今は違う。信頼できるインフラを選び、その上に乗ることがセキュリティ設計の核心になりつつある。GitHubを選ぶ、Cloudflareを選ぶ、大手クラウドを選ぶ。その選択自体が、セキュリティ体制の構築を意味する。
持たない設計と、巨人に乗る設計。この二つが組み合わさったとき、セキュリティ審査は「インフラは何を使っていますか」という一問に収束する。
6. 小さいことの、もう一つの強さ
大きな組織がセキュリティ審査に時間をかけるのは、それだけ多くのものを持っているからだ。複数のサーバー、複数のデータベース、複数のサービス、複数のチーム。それぞれについて証明しなければならない。
小さく、シンプルに保つことは、機能の制約ではなく、俊敏さの源泉だ。審査が速い、対応が速い、変更が速い。持つものが少なければ、守るものも少ない。守るものが少なければ、動くのが速い。
スタートアップが大企業に勝てる理由の一つは、ここにある。持たないことの身軽さは、スピードになり、コストの低さになり、審査の通過にもなる。
7. 設計思想は、審査票の短さに現れる
今日、FAQの解約手順が三行で済んだ話を書いた。決済の説明文が二十文字で済んだ話もある。そしてセキュリティ審査がほぼ一問で済んだ。
これらはすべて同じ根から生えている。サーバーにデータを持たない、という設計の原則だ。最初の一つの選択が、下流のあらゆる複雑さを消していく。
設計思想の純度は、後から現れる。審査票が短いとき、FAQが短いとき、説明が短いとき——それは設計の核心が一貫していた証拠だ。
セキュリティとは構築するものではなく、選ぶものだ。持たない設計と巨人に乗る設計が組み合わさるとき、審査は「何を使っていますか」の一問に収束する。