会社のセキュリティ教科書 第11部 11-3
スタートアップでも起きるセキュリティインシデント｜起きやすい7つの形と最初の一手
公開：2026年10月14日／最終更新：2026年10月14日／Moshiru 岡﨑 悠太
この手引きの要点（約25秒・音が出ます）
こんなときに役立ちます
- 少人数で急成長している会社が、何から守ればいいか知りたいとき
読み終えたあと、社内でこう言えます
「誰でも見られる設定と管理者の多要素認証を、点検して記録しました」
結論：人数の少ない会社で起きやすいのは、高度な攻撃よりも鍵の公開、公開設定のミス、消し忘れたアカウントです。総務省も、クラウドの設定ミスに絞ったガイドブックを出しています。
起きやすい3つ高度な攻撃よりも、こちらが多い
最初の一手は、漏れた鍵は消すより先に作り直す、「誰でも見られる」設定を一覧で探す、管理者に多要素認証を付けるの3つ。大企業との取引が始まると、チェックシートで同じ点を聞かれるので、点検の記録を残しておくと回答にも使えます。
最初の一手- 漏れた鍵は消すより先に作り直す
- 「誰でも見られる」設定を探す
- 管理者に多要素認証を付ける
起きやすい4つの形1鍵の公開キーを書いてコミット。まず作り直す
2公開設定開発中に公開のまま。一覧で確かめる
3消し忘れ退職者や委託のアカウントが残っている
4管理者全員が管理者。人数を絞り多要素認証
多くは設定と運用で防げる
起きやすい7つの形
1. APIキーやパスワードをGitHubなどに公開してしまう
なぜ起きるか：設定ファイルにキーを書いたままコミットする、個人のリポジトリに試しに上げる、などです。最初の一手：キーを無効にして作り直します。GitHubの公式ドキュメントも、最初にシークレットを失効・ローテーションするよう書いており、履歴を書き換えて消すだけでは確実とは言えないとしています。
鍵を公開してしまったら
公開リポジトリでは、GitHubのシークレットスキャンが無料で動き、プッシュ保護も既定で有効です。非公開のリポジトリでも設定を確かめておきます。
GitHubで確かめる1シークレットスキャン公開リポジトリは無料
2プッシュ保護既定で有効
3非公開リポジトリ設定を確かめる
2. クラウドの公開設定のミス
なぜ起きるか：総務省「クラウドの設定ミス対策ガイドブック」（2024年4月）は、既定値のまま使った例や、開発中に「公開」へ変えたまま戻さなかった例を挙げています。最初の一手：ストレージやデータベースの公開設定を一覧で確かめ、設定する人と確かめる人を分けます。
公開設定の点検- ストレージの公開設定
- データベースの公開設定
- 設定する人と確かめる人を分ける
3. SaaSの共有リンクと権限
なぜ起きるか：同じガイドブックには、ファイル共有サービスの公開範囲を誤り、顧客情報が「リンクを知っているインターネット上のすべての人」に見られる状態になった例があります。最初の一手：共有の設定画面で「リンクを知っている全員」になっているファイルを探し、社外に出す必要のないものを社内限定に戻します（画面の名前は変わることがあります）。
共有リンクの見直し- 1探す「リンクを知っている全員」
- 2見分ける社外に出す必要があるか
- 3戻す社内限定に
4. 退職者・業務委託のアカウントが残る
なぜ起きるか：入れ替わりが早く、契約の終わりとアカウントの削除が結び付いていないためです。ガイドブックも、退職者のアカウントや権限の削除漏れを挙げています。最初の一手：人の一覧とアカウントの一覧を突き合わせます。手順はアカウントの棚卸しにまとめています。
アカウントが残る理由入れ替わり早い
契約の終わり削除と結び付いていない
その結果アカウントが残る
人とアカウントの一覧を突き合わせる
5. 管理者アカウントの乗っ取り
なぜ起きるか：創業メンバー全員が管理者のまま、パスワードだけでログインしている、などです。ガイドブックは、管理者のIDとパスワードが漏れると乗っ取りや停止が起こりうるとしています。最初の一手：管理者を必要な人数に絞り、多要素認証を付けます。
管理者アカウント
6. 開発用のデータに本番の個人情報
なぜ起きるか：手早く動作を確かめるため、本番のデータを開発環境に写すためです。開発環境は守りが弱くなりがちです。最初の一手：開発にはダミーのデータを使います。本番の個人データが漏れた場合、不正アクセスによるものや1,000人を超えるものは、個人情報保護委員会への報告の対象です（報告と通知）。
開発用のデータ不正アクセスや1,000人超の漏えいは報告の対象
7. 大企業のセキュリティチェックで止まる
なぜ起きるか：IPA「情報セキュリティ10大脅威 2026」（組織編）の2位は「サプライチェーンや委託先を狙った攻撃」です。発注する側は委託先の対策を確かめるため、質問票を送ります。最初の一手：上の1〜6を点検し、日付と結果を残します。そのまま回答の裏付けになります。
10大脅威 2026（組織編）1〜6を点検し、日付と結果を残す
今週やる順番
- 管理者アカウントを数え、多要素認証を付ける。
- リポジトリと設定ファイルにキーが書かれていないか確かめ、見つけたら作り直す。
- クラウドのストレージと共有リンクで「誰でも見られる」ものを探す。
- 退職者・契約が終わった人のアカウントを止める。
- 開発環境に本番の個人データがないか確かめる。
今週やる順番- 1管理者に多要素認証
- 2キーを確かめる
- 3「誰でも見られる」ものを探す
- 4退職者を止める
- 5本番データの確認
取引や資金調達の前に聞かれること
大企業と取引を始めるときは、セキュリティチェックシートが届くことがよくあります。聞かれるのは、責任者、アカウントの管理、多要素認証、バックアップ、事故のときの連絡体制などです。答え方はチェックシートの答え方にまとめています。
よく聞かれること- 責任者
- アカウントの管理
- 多要素認証
- バックアップ
- 事故のときの連絡体制
経済産業省と内閣官房国家サイバー統括室が進める「SCS評価制度」は、取引先の対策の水準を★で示す仕組みで、IPAは2026年度下期の運用開始を想定しています。★3は専門家の確認付きの自己評価です（★3の準備）。手を付けずに残すと何が起きるかは、対策しないことの費用も参考にしてください。
SCS評価制度IPAは2026年度下期の運用開始を想定
よくある質問
社員が数人でも対策は必要ですか？
必要です。ただ、7つの形の多くは設定と運用で防ぐものです。高い製品を入れる前に、まず点検から始められます。
リポジトリを非公開にしていれば、キーを書いても大丈夫ですか？
非公開でも、メンバーの追加や外部サービスとの連携で見える人は増えます。キーは環境変数やシークレットの管理機能に置き、コードには書かない方が安全です。
チェックシートで「できていない」項目はどう書けばいいですか？
実態と違う内容は書かず、「いつまでに整える」と予定を添えて答えます。事実と違う回答は、あとで説明がつかなくなります。
参考にした資料
- 総務省「クラウドの設定ミス対策ガイドブック」（2024年4月）
- 総務省「クラウドの設定ミス対策ガイドブック」の公表（2024年4月26日）
- GitHub Docs「リポジトリからの機密データの削除」
- GitHub Docs「シークレットスキャンについて」
- IPA「情報セキュリティ10大脅威 2026」（2026年1月29日）
- IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録7 クラウドサービス安全利用の手引き
- 個人情報保護委員会「漏えい等の対応とお役立ち資料」
- IPA「SCS評価制度の詳細情報」（2026年5月29日更新）