# 認証情報とは

システムやサービスに本人や正規のプログラムとして接続するための情報の総称です。人のものとプログラムのものの違い、優先して守るアカウント、漏えいしたときの対処を解説します。

## 認証情報とは

認証情報は、システムやサービスに、本人または正規のプログラムとして接続するための情報の総称です。英語ではクレデンシャルといいます。人が使うものの代表はログインIDとパスワードで、ログインした後にブラウザが保持し、次の操作でパスワードの入力を省くためのログイン状態の情報も、盗まれると同じ働きをします。プログラムが使うものには、APIキー、クラウドのアクセスキー、SaaS同士の連携のために発行される、接続を許可された証明の文字列であるトークン、データベースの接続用のパスワードがあります。

例えば、経理担当がクラウドの会計サービスにログインするIDとパスワードは人の認証情報です。販売管理システムが会計サービスへ売上を自動で送るときに使うAPIキーは、プログラムの認証情報です。どちらも、持っている人やプログラムを正規の利用者として扱わせる力を持ちます。オフィスビルの入館カードと同じで、拾った人もそのカードで入館できます。

![本人のパスワード、プログラムのAPIキー、盗んだ人が使う同じパスワードのどれも、サービスは正規の利用者として通すことを示す図。サービスは提示された情報だけで正規かを判断する](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-5675633f091259f0f7e8a6a4c235619cccd1a056d3f702d73a388647d61f377e.png)

多要素認証は、パスワードと利用者が所持するスマートフォンのように性質の異なる要素を組み合わせて本人を確認する方式です。認証情報が確認に使う情報そのものであるのに対し、多要素認証はその組み合わせ方を指します。

## なぜ管理が必要か

認証情報を持つ者は、システムから正規の利用者として扱われます。盗まれた認証情報でログインされると、正規の利用者の操作と見分けにくく、不審な操作として検知しにくくなります。

ランサムウェアの侵入では、[未修正の脆弱性や設定の不備と並んで、漏えいした認証情報や簡易なパスワードを悪用する手口が多くを占めています](https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html)。Verizonの2025年版の報告書では、侵入の起点が判明した侵害のうち、人為的なミスと内部不正を除いた9,891件で、[盗まれた認証情報の利用が22%を占めます](https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/)。IPA（独立行政法人情報処理推進機構）は2026年10月の注意喚起で、利用している外部サービスについて、[作った覚えのないアカウントや、無効にしたはずなのに有効になっているアカウントがないかを点検するよう求めています](https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html)。

![侵入の起点が判明した侵害のうち、人為的なミスと内部不正を除いた9,891件を100マスで示し、22マスが盗まれた認証情報の利用にあたることを示す図。Verizonの2025年版の集計](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-1f44679e2631fa1c89440ccd228498d08baf1c6d0ae32102b967cc3c373aff11.png)

## 人のものとプログラムのもので漏えいの仕方が違う

人の認証情報は、利用者を狙った手口で盗まれます。

- 偽のログイン画面に入力させるフィッシング
- 別のサービスから漏えいしたIDとパスワードの組を使って他のサービスへのログインを試すパスワードリスト攻撃
- パソコンに感染したマルウェアによる、ブラウザに保存したパスワードやログイン状態の窃取

プログラムの認証情報は、主に保管した場所から漏えいします。

- ソースコードや設定ファイルへの書き込み。2025年にGitHubで公開されたコミットからは、[2,800万件を超える認証情報などの秘密情報](https://www.gitguardian.com/state-of-secrets-sprawl-report-2026)が見つかっている。公開したコードに書いた認証情報は、第三者に収集される前提で扱う。コミットはソースコードの変更の記録で、ソースコードを保管・共有する場所をリポジトリと呼ぶ
- チャットやメール、共有の表計算ファイルへの貼り付け
- 作成した担当者の異動や退職で持ち主が分からなくなり、無効にされないまま残る

人の認証情報は、利用者の注意と多要素認証で守ります。プログラムの認証情報は利用者が画面で操作しないため、保管場所、権限、有効期限の管理で守ります。

![人の認証情報は利用者が狙われて盗まれ、注意と多要素認証で守る。プログラムの認証情報は主に置き場所から漏れ、置き場所・権限・有効期限を限って守ることを対比した表](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-69f92d8f9f53f0034c0606a1a8078bf4d4a492bb362b82e4652419f8fb8aca73.png)

## 優先して守るもの

すべての認証情報を同時に整えることはできません。乗っ取られたときの影響が広いものから順に、多要素認証の設定と利用者の限定を進めます。目安の順番は次のとおりです。

1. シングルサインオンの管理者と、クラウドの最上位の管理アカウント。シングルサインオンは一度のログインで複数のサービスを使えるようにする仕組みで、その管理者が乗っ取られると連携する全サービスに影響する
2. 外部から接続できるサービスの管理者アカウント
3. 会社のメール。他のサービスのパスワードの再設定先になるため、乗っ取られると被害が別のサービスに広がる
4. 業務システムが使うプログラムの認証情報
5. その他の利用者のアカウント

![優先して守る順番を上から並べた図。シングルサインオンとクラウドの管理者、外部から接続できるサービスの管理者、会社のメール、業務システムが使うプログラムの認証情報、その他の利用者の順](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-37b8c1a2a12b5fe85595cca2004ebfd07c6f28800de791936e1cc96a7ca1afc2.png)

多要素認証も万能ではありません。偽サイトが本物のサイトとの間に入って中継するAiTM（Adversary-in-the-Middle）と呼ばれる手口では、[多要素認証を設定していても、ログイン状態の情報を盗まれてログインを迂回されます](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/)。上位の管理アカウントには、登録したサイトでしか使えないパスキーのような、偽サイトに中継されにくい方式を選びます。

## 管理の方法と負担

### 人の認証情報

パスワードは他のサービスと使い回さず、長く推測されにくいものをパスワード管理ツールに保管します。NIST（National Institute of Standards and Technology）のガイドラインは、[定期的な変更の強制を禁じ、漏えいの証拠がある場合は変更させることを要求しています](https://pages.nist.gov/800-63-4/sp800-63b.html)。

1つのIDを複数人で使う共有のアカウントは、誰の操作か分からず、退職者の分だけを止められません。サービスが許すなら1人1つのアカウントに分けます。SNSの公式アカウントのように分けられない場合は、パスワード管理ツールの共有機能で配り、利用者が抜けるたびにパスワードを変更します。

退職や異動のときに使っていたサービスを1つずつ止めるのは、利用するSaaSが増えると追い付きません。シングルサインオンでログインをまとめると、連携したサービスへの新たなログインを1か所で止められます。SaaSによってはシングルサインオンが上位の料金プランでしか利用できないため、その差額も導入の費用に含めます。

### プログラムの認証情報

ソースコードに書かず、[Google Cloud Secret Manager](https://docs.cloud.google.com/secret-manager/docs/overview)や[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)のような秘密情報を保管するサービスに置きます。用途ごとに分け、権限を絞り、設定できるなら有効期限を付けます。AWSは、[長期のアクセスキーより一時的な認証情報を使うよう勧めています](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)。

### 管理の負担

- 認証情報の一覧と、それぞれの持ち主と用途を把握する作業が継続する。プログラムの認証情報は、作った担当者しか所在を知らないことが多い
- 新しいものへの切り替えでは、それを使うシステムの設定も変える必要がある。古い認証情報を使う設定が1か所でも残っていると、その連携が停止する。漏えいした後も切り替えが済まないまま残ることは多く、2022年に公開リポジトリで見つかった時点で有効だった秘密情報の[64%が4年後も有効なまま](https://www.gitguardian.com/state-of-secrets-sprawl-report-2026)
- パスワード管理ツール、シングルサインオン、秘密情報の保管サービスの導入費用と、利用者への案内の工数がかかる
- 多要素認証では、端末を紛失したときの復旧の手順と支援が必要になる

![古い認証情報を無効にすると、新しいものに切り替え済みの会計と在庫の連携は稼働を続け、切り替えていない通知の連携だけが停止することを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-855814c7dddc16423d8fa8ee27d78f59b1718293ed205c424d7b9301804817eb.png)

導入の目安は次のとおりです。経験上の目安として、利用するSaaSが10を超えるか、従業員が数十人を超えたら、パスワード管理ツールとシングルサインオンを導入します。業務システムが外部のサービスと連携し始めた時点で、秘密情報の保管サービスを導入します。

## 漏えいしたときの対処

対処は、人のアカウントとプログラムの認証情報で異なります。

人のアカウントでは、パスワードを変更するだけでは終わりません。ログイン中の状態をすべて無効にし、登録された多要素認証の端末、メールの自動転送の設定、許可した連携アプリを点検します。攻撃者が自分の端末を認証方式として登録していると、パスワードを変えても再びログインされます。

プログラムの認証情報では、新しいものを発行して設定を切り替えてから、古いものを無効にします。悪用が進行している場合は、連携が止まることを受け入れて先に無効にします。GitHubは、[パスワードやトークンを誤って公開した場合、履歴の書き換えより先に無効化するか変更する](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)よう説明しています。

どちらも、無効にした後に、その認証情報で何ができたかを確認します。ログインの履歴、作成されたアカウント、変更された設定、取得されたデータを調べます。攻撃者が別の認証情報を新たに作っていると、元の認証情報を無効にしても接続が残ります。侵害が複数のシステムに及ぶ場合は、関係する認証情報をまとめて一斉に切り替えます。

![漏えいしたときの対処の流れを2段で示す図。人のアカウントはパスワードの変更、ログイン状態の無効化、登録端末の点検の順に進める。プログラムの認証情報は新しいキーの発行、設定の切り替え、古いキーの無効化の順に進め、悪用が進行中なら先に古いキーを無効にする。どちらも最後に利用履歴を確認する](https://media.marketing.kdotdev-tunnel.org/glossary-credentials-91fab56bf1b89e9577466acb86f76907a71d2f06604921b66ecaa3e144c3dd3a.png)

## よくある誤解

### パスワードを定期的に変更すれば安全

定期的な変更を強制すると、利用者は覚えられる範囲で変えようとして、末尾の数字を1つ増やすような推測しやすい規則で変えるようになります。NISTのガイドラインは定期的な変更の強制を認めず、[漏えいの証拠がある場合に変更を求めます](https://pages.nist.gov/800-63-4/sp800-63b.html)。変更の周期より、使い回しをやめることと多要素認証が効果的です。ただし、カード情報を扱う事業者向けの基準のように、パスワードだけで認証する場合に定期的な変更などを求める業界の基準もあるため、自社に適用される基準があればその規定に従い、なければ定期的な変更は求めません。

### 多要素認証を設定すれば認証情報の管理は要らない

多要素認証は人のログインを守る手段です。APIキーやアクセスキーのようなプログラムの認証情報は、それだけで接続でき、多要素認証の対象になりません。人のログインでも、ログイン状態の情報を盗まれると多要素認証を迂回されます。

### 社内向けのサービスの認証情報は狙われない

社内向けのサービスでも、[侵入した攻撃者はネットワーク内部を探索し、より多くのサーバーや端末の侵害を試みます](https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html)。社内向けのサービスの管理者アカウントも、外部向けと同じ順番で多要素認証と権限の絞り込みの対象にします。

認証情報の管理は、すべてを一度に整える必要はありません。人のものとプログラムのものを分けて一覧にし、乗っ取られたときに被害が広がる範囲の大きい、シングルサインオンの管理者アカウントとクラウドの最上位の管理アカウントから手を付けると、限られた工数でも、乗っ取られた場合の被害の範囲を先に狭められます。