PHPチームに外部の専門家を加える際、社内メンバーと同じ認証情報を渡す必要はありません。適切なアクセス権は作業内容によって異なります。コードの作成、エラーの再現、メトリクスの確認、デプロイの実行はそれぞれ別の作業であり、必ずしも同じシステムや権限を必要としません。
外部開発者のアクセス権を効果的に管理するには、対象範囲を限定し、個人ごとのIDを使い、期間を見直せるようにし、社内の責任者を明確にします。目的は作業を妨げることではなく、情報への露出を減らし、「誰が、どのシステムで、何を、いつまでできるのか」という実務上の問いに明確に答えられるようにすることです。
開発、テスト、デプロイ、調査を分ける
アカウントを作成する前に、アクセスが必要な作業を分類します。PHPの機能開発であれば、リポジトリ、技術ドキュメント、テストデータを使うローカル環境で十分な場合があります。変更の検証には、統合環境やステージング環境が必要かもしれません。コードのデプロイ、本番環境の参照、インシデントの調査はそれぞれ異なるケースであり、個別に評価する必要があります。
開発に本番環境へのアクセスが標準で必要なわけではありません。実際の問題を調査する必要がある場合は、まずログ、トレース、メトリクス、または隔離環境での再現によって診断できるか検討します。直接アクセスが必要なら、参照するリソース、許可する操作、権限の有効期限を明確にします。
コードを変更する権限と、リリースを公開する権限も区別しましょう。変更を準備してレビューに提出できても、デプロイ権限は持たない担当者を設定できます。同様に、メトリクスの読み取り権限があっても、アラートや設定を変更する権限があるとは限りません。
システムとアクセス関係を棚卸しする
棚卸しでは、ツールの一般的な一覧にとどまらず、個人と具体的なシステムを対応付けます。既存のPHPアプリケーションでは、少なくとも次の項目を確認します。
- リポジトリ：コード、保護ブランチ、レビュー設定、必要に応じて技術ドキュメント。
- 環境：開発、統合、テスト、ステージング、本番。それぞれに接続されているデータやサービスを記録します。
- データベース：インスタンス、スキーマ、許可する操作。作業が参照のみで済む場合は、書き込み権限を付与しないようにします。
- オブザーバビリティ：ログ、メトリクス、トレース、アラート、エラー追跡ツール。読み取りと管理の権限を区別します。
- 継続的インテグレーションとデプロイ：パイプライン、アーティファクト管理ツール、公開の仕組み。定義やシークレットを変更できる担当者を記録します。
- 接続サービス：アプリケーションで使用するストレージ、メール、決済、キュー、外部API、シークレット管理。
各項目について、ID、目的、権限レベル、承認する社内担当者、見直し日または有効期限を記録します。この棚卸しによって、間接的なアクセスも検出できます。たとえば、アカウントにサーバーへの直接アクセスがなくても、パイプラインの権限によって環境へのデプロイが可能な場合があります。
範囲を限定した個人別・一時的な権限を付与する
システムが対応している場合は、必ず個人別のアカウントを使用します。共有アカウントでは操作の帰属を確実に特定できず、権限の取り消しが難しくなり、認証情報が組織の管理外に残るおそれもあります。ツールが個別のIDに対応していない場合は、例外として記録し、アカウントを利用できる人と利用記録の方法を限定します。
最小権限の原則を適用し、現在の作業に必要な機能だけを付与します。たとえば、コードレビューではリポジトリの読み取り権限で足りる場合があります。変更を加える作業には書き込み権限が必要です。本番以外のデータベースでは、本番の認証情報を複製するのではなく、テスト用アカウントに架空のデータと限定的な権限を設定できます。
環境ごと、役割ごとに認証情報を分けます。本番で有効なシークレットを開発環境で再利用したり、ソースコード、共有ファイル、チケットに認証情報を記載したりしないでください。シークレットの保存には承認済みの仕組みを使い、参照やローテーションができる担当者を限定します。作業上シークレットを知る必要がない場合は、シークレットを見ずに済むよう環境を設定します。
権限の付与には、有効期限または明確な見直し時期を設定します。利便性を理由に無期限のアクセスにせず、期間を作業内容に合わせます。自動的な有効期限の設定は失念防止になりますが、責任範囲が変わったときや担当が終了したときの見直しに代わるものではありません。
申請、承認、見直しの手順を定める
アクセスの申請者、必要な理由、承認者、必要性を確認する方法という4項目が記録に残る、シンプルなフローを定めます。承認者は、アプリケーションやプラットフォームの責任者など、システムへの影響を評価できる社内担当者とします。機密性の高い権限については、社内プロセスに応じてセキュリティ部門や運用部門による追加確認が必要な場合もあります。
権限の付与や変更は、責任者が確認できる場所に記録します。パスワードやトークンを保存せずに、どの権限をいつ付与したか確認できる記録にします。作業内容の変更、協業期間の延長、データやデプロイに関わる権限の更新前など、重要なタイミングで見直しを行います。
インフラの権限とアプリケーションの権限は連携して管理しますが、混同しないでください。サーバーのアカウント、クラウドID、データベースユーザーは別々の制御です。いずれか1つを削除しても、ほかの権限がなくなるとは限りません。また、管理画面へのアクセスを付与しても、APIやパイプライン経由で可能な操作が制限されるとは限りません。
本番環境やインシデント対応の例外に備える
インシデントによっては、本番環境の参照や緊急対応が必要になる場合があります。例外を有効にする手順、アクセスを承認する人、許可する操作、作業の監督またはレビュー担当者をあらかじめ定めます。可能であれば自動的に期限切れとなる一時的な権限を使い、利用可能なアクティビティ記録を保持します。
緊急の変更では、運用設計上可能な限り、承認と実行を分けます。調査担当者が診断結果を提示したり変更を準備したりし、権限を持つ別の担当者が検証して公開します。同じ担当者が対応せざるを得ない場合は、その理由を記録し、事後レビューを行います。一時的な例外を恒久的な特権にしないでください。
参加、役割変更、離任の手順をテストする
手順に依存する前に、具体的なシナリオで検証します。参加時には、担当者が承認済みのアクセスだけを取得し、想定した環境で作業を完了できることを確認します。責任範囲が変わった場合は、以前の権限が見直され、新たな権限に理由と期限が設定されていることを確認します。
離任時には、リポジトリ、クラウド、データベース、オブザーバビリティ、パイプライン、接続サービスを含む棚卸し対象の各システムで、IDと権限を取り消します。認証情報が共有された可能性がある場合や、ユーザー単位で取り消せない場合は、ローテーションを行い、関連する利用状況を確認します。必要に応じて、アクティブなセッション、個人用トークン、APIキーも確認します。
最後に、アクセスの取り消しによって、運用上のプロセスに責任者がいなくならないことを確認します。スケジュールされたタスク、サービスアカウント、インテグレーション、パイプラインが外部担当者のIDに依存している場合があります。必要な自動化の唯一の所有者を個人アカウントにしないでください。それらのリソースに適切な社内IDと責任者を割り当て、個人のアクセスを削除した後も動作することを確認します。
再利用可能なチェックリスト
- 作業内容と必要なシステムを具体的に記述しているか。
- 開発、テスト、オブザーバビリティ、デプロイの権限を分けているか。
- 各アクセスに個人別のIDを使い、実行可能な範囲で最小限の権限にしているか。
- 認証情報を環境ごとに分け、ソースコードの外で管理しているか。
- 社内の承認者、記録、見直し日または有効期限を設定しているか。
- 本番環境の例外について、範囲、承認、レビューの方法を定めているか。
- 離任時にすべてのシステムを対象とし、共有認証情報のローテーションを考慮しているか。
- アクセス取り消し後も、自動化やサービスに責任者が割り当てられているか。
この方法によってすべてのリスクがなくなるわけではなく、アプリケーションのセキュリティ制御に代わるものでもありません。外部アクセスを検証し、必要に応じて調整できるようにします。具体的な必要性に基づいて付与し、その必要性が変わったときに見直し、作業終了時には連携して取り消せるようになります。
