「セキュリティ診断の結果をお伝えします」という一文から、その日のミーティングは始まった。ある製造業の経営者は、半年前に外部の開発会社へ依頼した基幹システムの改修が、ようやく落ち着いたところだった。ところが診断会社からの報告書には、思いもよらない指摘が並んでいた。GitHub上に公開されたソースコードのリポジトリの中に、決済代行サービスのAPIキーがそのままテキストで書き込まれていたのだ。しかもそのリポジトリは、外部から誰でも閲覧できる状態になっていた。半年間、誰にも気づかれることなく。
幸い、悪用された形跡はなかった。しかし担当者は青ざめた。もし誰かがそのキーを使って決済APIを不正に呼び出していたら、身に覚えのない請求が積み上がっていたかもしれない。顧客のカード情報が抜き取られていたかもしれない。「うちは大丈夫」と思っていたその油断こそが、実は一番の弱点だった。
この記事を読んでいるあなたも、もしかしたら似たような不安を抱えているかもしれない。外部サービスとの連携が増えるたびに、APIキーやパスワードのようなシークレット情報が増えていく。誰が何を持っているのか、どこに保管されているのか、正直なところ全部は把握できていない。それは決して恥ずかしいことではない。専門知識がなくても、外部サービス連携を安全に進めようと日々奮闘しているあなたに向けて、この記事では「実際にどこで漏洩が起きやすいのか」「どう管理すればいいのか」を、できるだけ具体的に解説する。
APIキー・シークレットとは何か、身構えずに理解する
APIキーという言葉を聞くと、専門的で難しいもののように感じるかもしれない。しかし本質はとてもシンプルだ。APIキーとは、あるシステムが別のシステムに対して「私は正当な利用者です」と証明するための鍵のようなものだ。人間がログインするときにIDとパスワードを使うのと同じ役割を、システム同士のやり取りでは、APIキーやアクセストークン、シークレットキーといった文字列が担っている。
たとえば、あなたの会社のシステムが決済サービスと連携している場合、そのシステムは決済サービス側に「このAPIキーを持っている自分は、御社と契約している正当な事業者です」と示すことで、決済処理を実行してもらえる。メール配信サービス、地図サービス、クラウドストレージ、チャットボットのAI連携なども、すべて同じ仕組みで動いている。
ここで押さえておきたいのは、APIキーはパスワードと本質的に同じ性質を持つということだ。知られてしまえば、持ち主になりすまして悪用される。しかもAPIキーは人間が入力するものではなく、プログラムの中に組み込まれて自動的に使われることが多いため、パスワードよりも管理の目が届きにくい。目に見えない場所に、目に見えない鍵が、いくつも埋め込まれている。それがシークレット情報の正体だ。
なぜシークレット情報は漏洩しやすいのか
APIキーの漏洩は、悪意ある第三者の高度なハッキングによって起きるとは限らない。むしろ多くの場合、現場で働く人たちの「早く動くものを作りたい」という前向きな姿勢や、日々の業務の中の小さな習慣が、結果的に漏洩の入り口になってしまう。
ソースコードへの直書き
開発の現場では、動作確認を急ぐあまり、APIキーをプログラムのコードの中に直接書き込んでしまうことがある。冒頭の事例のように、そのコードがGitHubなどのソースコード管理サービスにアップロードされ、しかも公開設定のままになっていると、世界中の誰もがそのキーを閲覧できる状態になる。実際、公開リポジトリを自動的に巡回してAPIキーを収集するプログラムが存在するといわれており、キーが公開された瞬間から不正利用までの時間は、決して長くない。
チャットやメールでの共有
「このAPIキー使ってね」とSlackやChatworkのチャットで気軽に共有してしまう場面も少なくない。開発を外部委託している場合、メールでキーをそのまま送ってしまうケースもよくある。チャットやメールの履歴は長期間残り続け、社内の誰もが検索できてしまうことが多い。悪気なく共有した情報が、退職者や関係のない担当者にまで見える状態のまま放置されてしまうのだ。
退職者への配布状態の放置
担当者が異動や退職をした後、その人がアクセスできていたAPIキーやアカウントの権限がそのまま残ってしまうケースは、想像以上に多い。「あの人はもういないから大丈夫」ではなく、「あの人が持っていたキーは今も有効なままかもしれない」という視点を持つ必要がある。特に中小企業では、システム担当者が一人しかおらず、その人が退職すると誰も全体像を把握していない、という状況に陥りやすい。
漏洩が引き起こす具体的な被害
APIキーの漏洩は、単なる「情報が漏れた」という抽象的な話では終わらない。実際に会社の経営に直結する被害となって現れる。
- クラウドサービスのAPIキーが漏洩し、第三者が大量の計算処理やデータ転送を行った結果、数百万円規模の利用料金が突然請求される
- 決済サービスのキーが悪用され、身に覚えのない取引が繰り返され、チャージバックの対応や取引先への信用回復に多大な労力を要する
- 顧客データベースへのアクセスキーが漏れ、氏名や連絡先、購買履歴といった個人情報が不正に取得され、個人情報保護法に基づく報告義務や、顧客への説明責任が発生する
- SNSアカウントの連携キーが乗っ取られ、会社名義でなりすまし投稿が行われ、ブランドイメージが大きく損なわれる
怖いのは、こうした被害の多くが「発覚するまでに時間がかかる」という点だ。冒頭の事例のように半年間気づかれないことも珍しくない。その間、静かに不正利用が進んでいる可能性を考えると、早期発見の仕組みづくりがいかに重要かが分かる。
基本的な管理のルール
難しい専門ツールを一からすべて導入する必要はない。まずは次の基本を押さえるだけで、リスクは大きく下がる。
コードに直書きしない
APIキーは、プログラムのコードそのものではなく、環境変数という仕組みを使って外部から与える形にするのが基本だ。環境変数とは、プログラムを動かすサーバーやパソコンごとに設定できる、コードの外側の値の置き場所のことを指す。こうしておけば、ソースコードがどこに公開されようと、キーそのものは含まれない。
専用の管理ツールを使う
チームでAPIキーを共有する必要がある場合は、チャットやメールではなく、シークレット管理専用のツールやパスワード管理サービスを使う。誰がいつどのキーにアクセスしたかの記録が残り、権限の取り消しもワンクリックでできる。中小企業でも、無料または低コストで使えるサービスは増えている。
定期的なローテーション
APIキーは一度発行したら使い続けるものではなく、定期的に新しいものに切り替える、いわゆるローテーションを行うのが望ましい。仮に過去に漏洩していたとしても、キーを更新すれば古いキーは無効になり、被害の拡大を止められる。半年に一度、あるいは担当者が変わるタイミングなど、社内でルールを決めておくとよい。
アクセス範囲を最小限にする
一つのAPIキーに、必要以上に強い権限を持たせないことも重要だ。読み取りしかしないはずの連携に、削除まで可能な権限を与えてしまうと、万が一漏洩したときの被害が桁違いに大きくなる。「この連携には何ができれば十分か」を、発注時から意識しておきたい。
発注時に開発会社に確認すべきポイント
外部の開発会社にシステム開発や改修を依頼するとき、非エンジニアの担当者がすべての技術的な妥当性を判断するのは難しい。しかし、次のような質問を投げかけるだけで、開発会社の姿勢や体制を見極める手がかりになる。
- APIキーやパスワードはソースコードに直書きせず、環境変数や専用の管理サービスで扱う方針になっているか
- ソースコードを管理するリポジトリは非公開設定になっているか、誰がアクセスできるか
- 納品後、開発会社側に残るアクセス権限やキーはあるか。プロジェクト終了時にどのように無効化するか
- 過去にセキュリティインシデントが発生した経験があるか、あった場合どう対応したか
こうした質問に対して、開発会社が具体的かつ淀みなく答えられるかどうかは、一つの信頼の指標になる。曖昧な返答しか返ってこない場合は、契約前に一度立ち止まって検討する価値がある。
よくある失敗パターン
これまで多くの現場で見られてきた失敗には、共通する型がある。
- 本番用のキーを、テスト環境や開発環境でもそのまま使い回してしまい、影響範囲を広げてしまう
- 「後で直そう」と思ったまま、テスト用に仮置きしたキーが本番稼働まで残ってしまう
- 複数の担当者が同じキーを共有し続け、誰がいつ使ったのか、誰がまだアクセスできるのか分からなくなる
- 外部委託先とのやり取りが個人のメールアドレスや個人のチャットアカウントで行われ、退職や契約終了後もキーが残り続ける
- そもそも「うちにはAPIキーなんて存在しない」と思い込み、棚卸しすら行われていない
最後の項目は特に見落とされがちだ。外部サービスとの連携が一つでもある会社には、必ずどこかにAPIキーが存在している。まずは「うちには何がどこにあるのか」を洗い出すことが、すべての対策の出発点になる。
まとめ
APIキーやシークレット情報の管理は、地味で目立たない仕事だ。うまくいって当たり前とみなされ、褒められることもあまりない。しかしその地道な積み重ねこそが、会社の信頼を守り、顧客の情報を守り、日々の事業活動を静かに支えている。
専門知識がなくても、今日からできることはある。まずは社内でどんな外部サービスと連携しているかを洗い出し、それぞれのAPIキーがどこに、誰の手に渡っているのかを確認してみてほしい。そして次にシステムを発注するときは、この記事で挙げた質問を一つでも投げかけてみてほしい。壁を一つ越えるたびに、会社は少しずつ強くなっていく。シークレット管理も、その壁の一つに過ぎない。完璧を目指す必要はない。今できる一歩を、着実に踏み出すことが何より大切だ。