※本稿は、2026年8月30日時点で公開されているGoogle Cloud、Microsoft、AWS、GitHubの公式資料に基づいています。管理画面の名称や利用できる機能は、契約プランや今後の仕様変更によって異なる場合があります。
※各サービスの認証方式や推奨事項は公式資料に基づく情報です。一方、台帳の項目、責任分担、確認頻度、社内ルールの例は、中小企業向けの実務上の提案です。
深夜にバックアップを実行する。
受注データを会計システムへ取り込む。
Webサイトから届いた問い合わせを顧客管理システムへ登録する。
生成AIのAPIを呼び出して、文書を自動作成する。
これらの処理では、人が画面へログインする代わりに、サービスアカウント、APIキー、クライアントシークレット、アクセスキーなどが使われることがあります。
問題は、このような認証情報について、次のような説明がされることです。
自動処理なので、特定の担当者はいません。
開発会社が作ったので、詳しいことは分かりません。
前任者が設定したもので、止めると何が起きるか分かりません。
人が毎日操作していなくても、その認証情報は会社の権限を使ってシステムへアクセスしています。
担当者がいないのではありません。
担当者を決めないまま、自動処理だけが動き続けている状態です。
2026年8月18日更新のMicrosoft公式資料では、Azure DevOpsからAzureへ接続する新しいサービス接続について、長期間有効なシークレットを保存する方式ではなく、ワークロードIDフェデレーションの利用が推奨されています。Microsoftは、この方式によってシークレットの作成・保存・更新が不要になると説明しています。既存のシークレット方式などは、互換性維持や一部の例外的な用途向けと位置付けられています。
Google Cloudも2026年5月、APIキーは使いやすい一方、不適切に管理すると、盗まれたキーによって環境が不正利用される可能性があるとして、制限、監視、削除などの対策を改めて案内しました。
今回は、サービスアカウントやAPIキーを利用している中小企業が、誰を責任者とし、何を台帳へ記録し、どのように更新・停止すればよいかを整理します。
サービスアカウントとAPIキーは同じものではない
サービスアカウント、APIキー、クライアントシークレットという言葉は、同じ意味で使われることがあります。
しかし、正確には「誰としてアクセスするのか」と「何を使って本人であることを証明するのか」を分けて考える必要があります。
| 用語 | 主な役割 | 例 |
|---|---|---|
| サービスアカウント | プログラムや自動処理を表すID | Google Cloudのサービスアカウント |
| サービスプリンシパル | アプリケーションやサービスを表すID | Microsoft Entra IDのサービスプリンシパル |
| マネージドID | クラウド側で認証情報を管理するワークロード用ID | Azure Managed Identity |
| APIキー | APIを呼び出すために使う文字列 | 生成AI、地図、翻訳APIなど |
| クライアントシークレット | アプリケーションが自身を証明する秘密情報 | Microsoft Entra IDのシークレット |
| アクセスキー | プログラムからクラウドへ接続するための認証情報 | AWSのアクセスキー |
| 証明書・秘密鍵 | アプリケーションの認証に使う暗号鍵 | サービスプリンシパル用証明書 |
| アクセストークン | 認証後に発行される、通常は有効期間の短い情報 | OAuthアクセストークン |
Microsoftは、サービスプリンシパルを、利用者ではなくアプリケーションやサービスを識別するセキュリティ主体と説明しています。クライアントシークレットは、そのサービスプリンシパルが自身を証明するためのパスワードに相当します。
Google Cloudのサービスアカウントキーは、サービスアカウントとして認証するための秘密鍵です。サービスアカウントというIDと、ダウンロードした鍵ファイルは別のものです。
APIキーの性質はサービスによって異なります。
単に利用するプロジェクトや契約を識別するものもあれば、一定の権限を伴う認証情報として使われるものもあります。そのため、「APIキーだから重要度は低い」「パスワードではないから漏れても問題ない」とは判断できません。
人が使わない認証情報にも責任者が必要
社員用のアカウントであれば、通常は利用者が分かります。
一方、サービスアカウントには、次のような名称が付いていることがあります。
systembatchbackupapi-usertestservice01admin-api- 開発会社名だけが入ったアカウント
名称だけでは、何に使われているか分かりません。
作成した技術者が退職した後も処理が動き続け、数年後に初めて、誰も停止方法を知らないことが分かる場合があります。
責任者がいない認証情報には、主に四つの問題があります。
不正利用されても影響を判断できない
キーが漏えいしても、どのシステム、データ、権限に関係するか分からなければ、調査と停止の判断が遅れます。
有効期限切れで業務が停止する
Microsoft Entra IDでは、サービスプリンシパルの証明書やクライアントシークレットが期限切れになると、サービスプリンシパルが認証できなくなり、自動処理が停止する可能性があります。Microsoftは、有効期限が30日以内に迫った認証情報を確認する推奨機能を提供しています。
不要になっても削除されない
開発、試験、移行、短期キャンペーンなどで作成されたキーが、利用終了後も残ることがあります。
Google Cloudは、不要なサービスアカウントやキーを無効化・削除し、有効な認証情報の数を減らすことを推奨しています。サービスアカウントが過去90日間認証に使われていないことを確認する機能や、最後の利用状況を調べる機能も案内しています。
誰が操作したか分からない
複数のシステムが一つのAPIキーやサービスアカウントを共有すると、ログに同じIDしか残らず、どのプログラムが操作したかを特定しにくくなります。
一つの認証情報を、複数の用途へ安易に使い回さないことが重要です。
長期間有効な鍵を置かない方向へ変わっている
Google Cloud、Microsoft、AWSの公式資料に共通しているのは、長期間有効な認証情報をファイルや設定値として保存する方式を、できる限り減らすという考え方です。
Google Cloudは、より安全な代替手段を利用できる場合、サービスアカウントキーの作成を例外として扱うよう推奨しています。2024年5月3日以降に作成された組織では、サービスアカウントキーの新規作成を禁止する組織ポリシーが、既定で適用されています。
Microsoftは、Azure上の処理ではマネージドIDを、Azure外の処理やGitHub ActionsなどではワークロードIDフェデレーションを利用することで、シークレットを保管せずに認証する方法を案内しています。
AWSも、人が使うアカウントだけでなく、アプリケーションなどのワークロードについて、長期アクセスキーではなく、IAMロールによって発行される一時的な認証情報を使用することを推奨しています。
考え方を簡単にまとめると、次の順序になります。
- クラウドが管理するマネージドIDやIAMロールを利用する
- 外部システムとはワークロードIDフェデレーション等を利用する
- 必要に応じて有効期間の短いトークンを利用する
- 代替できない場合に限り、証明書、シークレット、長期キーを利用する
全ての既存システムを直ちに変更できるわけではありません。
しかし、新しいシステムを作るたびに長期キーを発行しているのであれば、認証方式を見直す余地があります。
最初に認証情報を棚卸しする
管理を始めるためには、現在どのようなサービスアカウントやキーが存在するかを確認します。
クラウド管理画面だけでなく、次の場所も確認対象です。
- Google Cloud、Microsoft Azure、AWSの認証情報一覧
- GitHub、GitLabなどのソースコード管理サービス
- CI/CDのシークレット設定
- サーバーやパソコンの環境変数
- 設定ファイル
- Windowsのタスクスケジューラ
- Linuxのcron
- RPAやローコードツール
- バックアップソフト
- 監視サービス
- 会計、勤怠、顧客管理等のSaaS連携
- Webサーバーやレンタルサーバー
- 開発会社が管理している環境
- 社内チャットやメールの過去のやり取り
- 担当者のダウンロードフォルダ
Google Cloudは、サービスアカウントキーをソースコードへ登録しないこと、プログラムの実行ファイルへ埋め込まないこと、作成時にダウンロードした鍵を一時フォルダへ残さないことを案内しています。
GitHubのシークレットスキャンは、リポジトリ内の履歴を対象に、APIキー、パスワード、トークンなどの既知の認証情報を検出します。プッシュプロテクションを利用すると、認証情報を含む可能性があるデータがリポジトリへ登録される前に停止できます。
ただし、検出機能があるから漏えいしないとは限りません。
検出対象外の形式、独自のキー、画像や文書に書かれた認証情報などは、見つからない場合があります。自動検出と台帳管理を組み合わせる必要があります。
認証情報台帳に記録する項目
認証情報台帳には、秘密情報そのものではなく、管理に必要な情報を記録します。
| 管理項目 | 記録する内容 |
|---|---|
| 管理番号 | 台帳内で一意となる番号 |
| 名称 | サービスアカウント名、キーの表示名 |
| 種類 | APIキー、アクセスキー、シークレット、証明書など |
| 利用サービス | Google Cloud、Azure、AWS、外部SaaSなど |
| 対象環境 | 本番、開発、検証 |
| 利用目的 | バックアップ、データ連携、通知など |
| 利用システム | 認証情報を使用するプログラムや機器 |
| 業務責任者 | 利用継続の必要性を判断する人 |
| 技術担当者 | 設定変更、更新、停止を行う人 |
| 代理担当者 | 主担当者が不在のときに対応する人 |
| 権限 | 読取り、書込み、削除、管理など |
| 対象データ | 顧客情報、会計情報、ファイルなど |
| 保管場所 | Key Vault等の名称。秘密情報自体は書かない |
| 作成日 | 認証情報を作成した日 |
| 有効期限 | 証明書やシークレットの失効日 |
| 最終利用日 | 最後に利用されたことを確認した日 |
| 最終更新日 | 最後にローテーションした日 |
| 次回確認日 | 棚卸しまたは更新の予定日 |
| 緊急停止方法 | 無効化、削除、権限剥奪などの手順 |
| 停止時の影響 | 停止する業務、代替手段 |
| 委託先 | 開発・保守事業者と連絡先 |
| 判定 | 継続、移行予定、停止予定、要確認 |
APIキー、クライアントシークレット、秘密鍵そのものを、Excelや一般的な台帳へ記載してはいけません。
Microsoftは、APIキー、クライアントシークレット、サービスプリンシパルの認証情報などをAzure Key Vaultのような秘密情報管理機能へ保存し、所有者、更新予定、有効期限などの管理情報はタグとして記録する方法を案内しています。
台帳には「秘密情報がどこに保管されているか」だけを記録します。
業務責任者と技術担当者を分ける
サービスアカウントの責任を、技術担当者一人だけへ負わせると、利用継続や停止の判断ができないことがあります。
次の役割を分けて決めます。
| 役割 | 主な責任 |
|---|---|
| 業務責任者 | その自動処理が業務上必要か判断する |
| 技術担当者 | 作成、設定、更新、ログ確認を行う |
| 承認者 | 権限や利用開始を承認する |
| 代理担当者 | 主担当者が不在のときに対応する |
| 緊急判断者 | 漏えい時に停止を決定する |
| 委託先 | 契約範囲内の技術作業を行う |
例えば、毎晩の請求データ連携であれば、経理部門が業務責任者、システム保守会社が技術担当者、管理部長が承認者という分担が考えられます。
開発会社が技術的な作業を担当していても、利用を続けるかどうかを開発会社だけで決めることはできません。
会社側に業務責任者が必要です。
Microsoft Entra IDでは、アプリケーションやエンタープライズアプリケーションへ所有者を設定できます。ただし、アプリケーション自体が高い権限を持つ場合、所有者はそのアプリケーション設定を通じて強い操作が可能になることがあります。所有者は必要な人に限定してください。
一つのキーを複数のシステムで使い回さない
管理を簡単にするため、一つのAPIキーやサービスアカウントを複数のシステムへ設定することがあります。
しかし、一つのキーを使い回すと、次の問題が起こります。
- どのシステムから利用されたか分からない
- 一つのシステムで漏えいすると、全システムのキー変更が必要になる
- 一つの処理を停止したいだけでも、他の処理まで止まる
- 必要な権限が異なるのに、最も強い権限へ統一される
- 開発環境から本番環境へアクセスできる状態になる
原則として、次の単位で認証情報を分けます。
- 利用システム
- 利用目的
- 本番・開発・検証環境
- 委託先
- 権限
- 接続先
例えば、「全社共通APIキー」ではなく、次のように分けます。
- 顧客管理システムからメール配信サービスを使うキー
- Webサイトからメール配信サービスを使うキー
- 開発環境からメール配信サービスを使うキー
キーを分ければ、問題が起きたシステムだけを停止しやすくなります。
APIキーへ利用制限を設定する
利用するサービスが対応している場合は、APIキーへ制限を設定します。
Google Cloudでは、主に次の二種類の制限を設定できます。
| 制限 | 内容 |
|---|---|
| API制限 | そのキーで利用できるAPIを限定する |
| アプリケーション制限 | 利用元のWebサイト、IPアドレス、アプリ等を限定する |
Google Cloudは、API制限とアプリケーション制限の両方を設定することを推奨しています。制限のないAPIキーは、対応するAPIへ広く使用できたり、任意の場所から利用できたりする可能性があります。
サービスによっては、次のような制限を設定できます。
- 接続元IPアドレス
- 利用できるWebサイトのドメイン
- Android・iOSアプリの識別情報
- 利用できるAPI
- 1日または1分当たりの利用量
- 利用できる環境
- アクセスできるデータ
全てのAPIサービスが同じ制限機能を提供しているわけではありません。
利用中のサービスの仕様を確認してください。
ブラウザやスマートフォン内のキーは「隠せない」場合がある
Webブラウザやスマートフォンのアプリから、外部APIを直接呼び出す構成では、APIキーが利用者の端末へ送られる場合があります。
その場合、プログラムの中で文字列を分割したり、簡単な暗号化をしたりしても、端末上で利用できる以上、完全に秘密にすることは困難です。
可能であれば、利用者の端末から自社のサーバーへリクエストを送り、自社サーバー側でAPIキーを付けて外部APIを呼び出します。
サービスの仕様上、ブラウザやアプリ内でキーを使用する必要がある場合は、次の対策を組み合わせます。
- 利用可能なWebサイトやアプリを限定する
- 利用できるAPIを限定する
- 利用量の上限を設定する
- 異常な利用を監視する
- 本番用と開発用を分ける
- 個人情報等へアクセスできる強い権限を持たせない
Google Cloudも、APIキーをクライアント側のコードへ安易に埋め込まず、可能であればサーバー側で認証情報を追加する構成を案内しています。
URLにAPIキーを付けない
次のように、APIキーをURLの一部として送信する実装があります。
URLは、次の場所へ記録される可能性があります。
- ブラウザ履歴
- Webサーバーのアクセスログ
- プロキシサーバー
- WAF
- アクセス解析
- エラー記録
- 画面共有やスクリーンショット
Google Cloudは、APIキーをクエリパラメーターとしてURLへ含めると、URLの収集等によって盗まれる可能性があるため、対応するAPIではHTTPヘッダーや公式クライアントライブラリを利用するよう案内しています。
ログを確認するときも、URL、エラーメッセージ、デバッグ出力へAPIキーが記録されていないかを確認してください。
ソースコードから消すだけでは失効しない
APIキーや秘密鍵を誤ってGitHub等へ登録した場合、後から該当行を削除しても、漏えいへの対応は完了しません。
ソースコード管理サービスには、過去の変更履歴が残ることがあります。また、既に第三者がキーを取得している可能性もあります。
Google Cloudは、サービスアカウントキーをリポジトリへ誤って登録した場合、リポジトリ上から削除するだけでは不十分であり、IAM上で該当キーを速やかに削除する必要があると説明しています。
対応の基本は次のとおりです。
- 該当するキーを特定する
- 新しいキーまたは代替認証方式を準備する
- 利用中のシステムを切り替える
- 漏えいしたキーを無効化または削除する
- 不正利用の有無をログで確認する
- 利用料金やデータアクセスへの影響を確認する
- リポジトリやログから秘密情報を除去する
- 同じキーが他の場所へ保存されていないか確認する
Google Cloudは、公開リポジトリ等で漏えいが検出されたサービスアカウントキーを、自動的に無効化する仕組みを2024年6月から既定で有効にしています。ただし、Googleは全ての漏えいを検出できるとは保証していません。
「クラウド事業者が見つけてくれる」と考えず、自社でも検出と停止の手順を準備する必要があります。
有効期限が短ければ、それだけで安全とは限らない
長期間有効な認証情報より、有効期間が短い認証情報の方が、漏えい時の影響を限定しやすくなります。
一方、有効期限を設定しただけで更新手順を作っていない場合、期限切れの日に業務が停止します。
Microsoftは、クライアントシークレットや証明書が期限切れになると、サービスプリンシパルが認証できず、業務停止につながる可能性があると説明しています。
Google Cloudでは、利用者が作成してダウンロードするサービスアカウントキーは、通常、削除するまで有効であり、有効期限を設定すると漏えい時の影響を減らせる一方、更新を忘れるとワークロードが停止する可能性があります。
そのため、有効期限と更新予定をセットで管理します。
実務上は、例えば次のような通知日を設定できます。
| 時期 | 実施すること |
|---|---|
| 60日前 | 更新担当者と対象システムを確認する |
| 30日前 | 新しい認証情報を発行し、試験環境で確認する |
| 14日前 | 本番環境の切替日を決定する |
| 7日前 | 未切替のシステムがないか確認する |
| 切替日 | 新しい認証情報へ変更する |
| 切替後 | 旧認証情報を無効化し、動作を監視する |
| 確認後 | 旧認証情報を削除する |
この日数は公的な統一基準ではありません。
利用サービスの仕様、業務の重要度、変更手続、委託先との調整期間に応じて決めてください。
ローテーションは「古いキーを先に消す」作業ではない
認証情報を更新することを、ローテーションと呼びます。
安全に更新する基本的な順序は次のとおりです。
- 新しい認証情報を作成する
- 新しい認証情報へ必要最小限の権限を付与する
- 対象システムへ新しい認証情報を設定する
- 正常に動作することを確認する
- 古い認証情報を無効化する
- 業務やログを一定期間確認する
- 問題がなければ古い認証情報を削除する
Google Cloudも、サービスアカウントキーの更新について、新しいキーを作成し、各システムを切り替え、旧キーを無効化して動作を確認した後、旧キーを削除する手順を案内しています。Googleは、管理するサービスアカウントキーについて、少なくとも90日ごとの更新を推奨していますが、これはGoogle Cloudのサービスアカウントキーに関する推奨であり、全てのサービスへ一律に適用される基準ではありません。
MicrosoftのAzure Key Vault資料では、組織の方針や情報の重要度に応じて、例えば60日から90日といった短い間隔で更新し、無停止で切り替えられるよう二組の認証情報を利用する方法が示されています。
実際の更新間隔は、サービスの仕様、権限、漏えい時の影響、更新の自動化状況を踏まえて決めてください。
利用されていないキーは、まず無効化して確認する
台帳に用途不明のキーが見つかっても、直ちに削除すると、業務システムが停止する可能性があります。
通常の棚卸しでは、次の順序で進めます。
- 最終利用日時を確認する
- 利用しているシステムと担当者を調べる
- 一時的に無効化する
- 業務影響とエラーを監視する
- 問題がなければ削除する
Google Cloudでは、サービスアカウントやキーの利用状況を確認する指標が提供されています。AWSでも、アクセスキーが最後に利用された日時、利用したAWSサービス、リージョンを確認できます。
AWSは、最終利用情報だけを見て直ちに古いアクセスキーを削除するのではなく、まず無効化して影響を確認する方法を案内しています。
ただし、漏えいが確認された認証情報は別です。
通常の棚卸しよりも被害拡大防止を優先し、速やかな無効化、削除、権限剥奪を検討してください。
キーを無効化しても、発行済みトークンが残る場合がある
認証情報を無効化すれば、その瞬間に全てのアクセスが停止するとは限りません。
例えばGoogle Cloudでは、サービスアカウントキーを無効化しても、そのキーを使って既に発行された有効期間の短い認証情報は、直ちに取り消されない場合があります。発行済み認証情報まで停止する必要がある場合は、サービスアカウント自体の無効化または削除が必要になることがありますが、そのサービスアカウントを使う全ての処理が停止します。
緊急停止手順には、次の違いを記載してください。
- APIキーだけを削除する
- サービスアカウントキーを無効化する
- クライアントシークレットを削除する
- セッションやトークンを失効させる
- サービスアカウント自体を無効化する
- 付与した権限を取り消す
- 接続先サービス側でも連携を解除する
「キーを消したので対応完了」と判断せず、利用中の認証方式に応じて確認します。
シークレットを持たない認証へ移行する
長期間有効なキーやシークレットを安全に保管・更新することには、継続的な負担があります。
利用する環境が対応している場合は、キーそのものを保存しない方式へ移行します。
Azure上の自動処理
AzureのマネージドIDを利用すると、アプリケーション内にクライアントシークレットやアクセスキーを保存せず、Azure側で管理されるIDを使って他のサービスへ接続できます。
AWS上の自動処理
EC2やLambda等では、IAMユーザーの長期アクセスキーを保存する代わりに、IAMロールによって一時的な認証情報を取得できます。
Google Cloud外からGoogle Cloudへ接続する処理
Workload Identity Federationを利用すると、外部の処理が長期間有効なサービスアカウントキーを保持せず、信頼関係に基づいてGoogle Cloudへアクセスできます。
GitHub Actionsからクラウドへ接続する処理
GitHub Actionsでは、OIDCを利用することで、長期のクラウド認証情報をGitHubのシークレットへ保存せず、ジョブ単位で有効期間の短いトークンを取得できます。
ただし、キーを持たない方式へ変更しても、権限管理が不要になるわけではありません。
どのリポジトリ、処理、環境が、どのクラウド資源へアクセスできるかを適切に制限する必要があります。
移行を優先したい認証情報
全てを一度に変更できない場合は、次の認証情報から優先して見直します。
| 優先度 | 認証情報の状態 |
|---|---|
| 最優先 | 漏えいした可能性がある |
| 最優先 | 公開リポジトリや公開ファイルへ含まれていた |
| 高 | 管理者権限や広い書込み・削除権限を持つ |
| 高 | 責任者や利用目的が分からない |
| 高 | 複数のシステムで共用されている |
| 高 | 本番と開発で同じ認証情報を使っている |
| 中 | 長期間更新されていない |
| 中 | 有効期限がない |
| 中 | 最終利用日時が分からない |
| 中 | パソコンやサーバーの設定ファイルに平文で保存されている |
| 中 | CI/CDで長期キーを使用している |
| 低 | 権限、所有者、更新、監視が適切に管理されている |
漏えいや管理者不明の認証情報を先に対応し、その後、長期キーをマネージドIDやワークロードIDへ段階的に移行する方法が現実的です。
開発会社へ確認する事項
外注したシステムでサービスアカウントやAPIキーを使っている場合は、開発会社へ次の事項を確認します。
当社向けシステムで利用しているサービスアカウント、APIキー、アクセスキー、クライアントシークレット、証明書を一覧で提示してください。
各認証情報について、利用目的、対象システム、付与権限、保管場所、作成日、有効期限、最終更新日、停止方法、停止時の影響を回答してください。
認証情報そのものをメールへ記載せず、秘密情報管理機能等の安全な方法で管理してください。
マネージドID、IAMロール、ワークロードIDフェデレーションなど、長期キーを保存しない方式へ変更できるか回答してください。
「開発会社が保管しています」という回答だけでは不十分です。
少なくとも、会社側が次の情報を把握する必要があります。
- 何個存在するか
- 何に使われているか
- どの権限を持つか
- いつまで有効か
- 誰へ連絡すれば停止できるか
- 開発会社を変更した場合に引き継げるか
社内ルールの記載例
社内規程やクラウド利用手順には、次のように記載できます。
サービスアカウント、APIキー、アクセスキー、クライアントシークレット、証明書その他の機械的な認証情報を作成する場合は、利用目的、業務責任者、技術担当者、対象システム、付与権限、保管場所および有効期限を明確にし、管理責任者の承認を受ける。
認証情報は、ソースコード、一般的な共有フォルダ、メール、社内チャット、チケット、手順書または表計算ファイルへ平文で保存してはならない。
利用サービスがマネージドID、IAMロール、ワークロードIDフェデレーションその他の長期認証情報を保存しない方式へ対応している場合は、当該方式を優先する。
認証情報へ付与する権限は、利用目的に必要な最小限とし、本番・開発・検証環境および利用システムごとに分離する。
管理者は、認証情報の有効期限、最終利用日時、利用目的および責任者を定期的に確認し、不要となった認証情報を無効化した後、業務影響を確認して削除する。
認証情報の漏えいまたは不正利用が疑われる場合、従業員および委託先は、自己判断で記録を消去せず、直ちに管理責任者へ報告する。
これは法令やクラウド事業者が指定した統一文面ではありません。
自社の体制、利用サービス、委託契約に合わせて修正してください。
棚卸しの頻度
全ての認証情報を毎月詳しく調査することは、中小企業にとって負担になる場合があります。
実務上は、次のように分ける方法があります。
| 確認時期 | 確認する内容 |
|---|---|
| 毎月 | 新規作成、削除、有効期限、漏えい警告 |
| 四半期ごと | 最終利用日、権限、責任者、不要キー |
| 半年ごと | 保管場所、緊急停止手順、委託先情報 |
| 年1回 | 全体棚卸し、長期キーからの移行計画 |
| 随時 | 担当者変更、システム変更、事故、契約終了 |
これは公的な統一基準ではありません。
認証情報の権限、扱うデータ、システム停止時の影響などに応じて調整してください。
特に、管理者権限を持つもの、個人情報へアクセスするもの、利用料金が発生するAPIなどは、短い間隔で確認する必要があります。
15分で始める最初の確認
まず、Google Cloud、Microsoft Azure、AWS、利用中のSaaSから一つを選び、認証情報の一覧を開きます。
次の六つを確認してください。
- 名称だけでは用途が分からない認証情報がないか
- 業務責任者と技術担当者を答えられるか
- 有効期限が30日以内に迫っていないか
- 長期間利用されていない認証情報がないか
- 必要以上に広い権限が付いていないか
- 停止した場合に影響するシステムを説明できるか
六つ全てに答えられる必要はありません。
回答できなかった項目を台帳へ「要確認」と記録し、担当者と期限を決めるところから始めます。
経営者が確認したい五つの質問
経営者が、OAuthやクラウドIAMの技術仕様を全て理解する必要はありません。
まず、担当者へ次の五つを確認してください。
- 自動処理が利用しているサービスアカウントやAPIキーを一覧にできるか
- 各認証情報について、業務責任者と技術担当者が決まっているか
- 漏えいした場合に、何を止め、どのログを確認するか決まっているか
- 有効期限や更新日を管理し、業務を止めずに切り替えられるか
- マネージドIDやワークロードIDなど、長期キーを置かない方式へ変更できないか検討しているか
この五つに答えられなければ、会社の権限を持った「見えない利用者」が、管理されないまま動いている可能性があります。
まとめ
サービスアカウントやAPIキーは、人が毎日ログインするアカウントではありません。
しかし、会社のシステム、データ、クラウド環境へアクセスするための重要な認証情報です。
人が操作しないことを理由に、担当者を決めなくてよいわけではありません。
重要なのは、次の点です。
- サービスアカウントと認証情報を分けて把握する
- 利用目的、業務責任者、技術担当者を決める
- 本番・開発・システムごとに認証情報を分ける
- 必要最小限の権限と利用制限を設定する
- 秘密情報管理機能へ保存する
- 有効期限と更新予定を管理する
- 不要な認証情報は無効化してから削除する
- 漏えい時の停止と調査手順を決める
- 可能な場合は長期キーを置かない方式へ移行する
まずは、自社で動いている自動処理を一つ選んでください。
そして、次の質問へ答えられるか確認します。
この処理は、どの認証情報を使い、どの権限で、どのデータへアクセスし、問題が起きたら誰が止めるのか。
答えられなければ、その自動処理には「担当者がいない」のではありません。
会社が、担当者を決めていないだけです。
ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象に、サービスアカウント、APIキー、クラウド権限、SaaS連携、外部委託先などの棚卸しを支援しています。
全ての自動処理を停止することが目的ではありません。
誰が、何の目的で、どの権限を利用しているかを明確にし、安全に運用を続けられる状態を作ることが重要です。
- 投稿タグ
- APIキー, アクセスキー, キーローテーション, クライアントシークレット, クラウドIAM, サービスアカウント, サービスプリンシパル, シークレット管理, マネージドID, ワークロードID, 中小企業セキュリティ, 最小権限, 認証情報
