Capordiaアクセスを配布する前に責任者を定める
レンタル案件の責任者、プロジェクトへのアクセスを承認する人、ターゲット上で技術的な変更を適用できる人を区別してください。結果の責任者が必ずしもプロセスを起動したりマシンを管理したりする必要はありません。権限を選ぶ前に、必要な操作を書き出します。エクスポートを読む、入力を配置する、タスクを実行する、環境を変更する、などです。
次に、実際に付与されたアクセスの範囲を確認します。アイデンティティの作成や権限設定の権限がない場合は、他の関係者を招待する前に、可能な手順を確認してもらってください。Capordia アカウントのパスワードを配布してこの制限を回避しないでください。作業の分担と商取引案件の管理は別の問題です。
個人単位の識別情報を使用し、その適用範囲を把握する
個人単位の識別情報を使用すれば、チーム全体のアクセスを入れ替えることなく、ある一人のアクセスを取り消せます。鍵によるSSH運用を行う組織では、OpenSSHはサーバーが把握している公開鍵と、利用者が保持する秘密鍵を区別します。連携用ドキュメントには公開鍵の参照やフィンガープリントを記載してもかまいませんが、秘密鍵やそのパスフレーズを記載してはなりません。
同じシステムアカウントにアクセスできる2つの異なるキーは、自動的に2つの異なるファイル範囲を作成するわけではありません。権限はアカウントと、マシン上で構成されたメカニズムに依存します。したがって、要件が個人認証のみを対象とするのか、アクションの分離にも及ぶのかを決定してください。自動化については、同僚の個人IDを密かに再利用することなく、明示的なIDと所有者を用意してください。
識別情報を提示する前に接続先を確認する
初回アクセス時には、アクセス引き渡しのプロセスで得た信頼できる参照情報に基づき、マシン名、想定されるアカウント、そのホスト鍵のフィンガープリントを確認してください。このホスト鍵はサーバーを識別するものであり、あなたのユーザー鍵とは別物です。サーバーの識別情報が変わったという予期しないメッセージは、既知の参照情報を自動的に削除するのではなく、確認する価値があります。
OpenSSHはホスト鍵を保持し、その変更を通知します。この情報は、告知されたマシンの再構築、変更されたアドレス、説明のつかない事象といった状況と合わせて活用してください。予期しない変更であれば、続行する前に確認を取ってください。目的は接続のたびに儀式を増やすことではなく、識別情報に関する警告を単なる表示上の煩わしさとして扱わないようにすることです。
架空の例：3人の関係者、3つのニーズ
架空のチーム「Dossier des ouvrages」が1週間の作業を準備しています。IdrissはプロジェクトAの処理を実行し、Noémieはエクスポートをレビューし、Sachaは環境設定のために一時的に参加します。チームは表の権限を望んでいますが、実際に引き渡されるシステムでそれが適用可能かを確認する必要があります。これは既存の顧客アカウントでも、Capordiaが告知するチーム管理機能でもありません。
決定的な原則は、Noémieが結果を開くために管理者アクセスを取得しないこと、そしてSachaの作業には終わりがあることです。人間による承認だけでは権限は一切設定されません。技術責任者が利用可能な仕組みを適用し、その後それぞれが予定された確認を実行します。望ましい分離が実現できない場合、プロジェクトはその分離を必要とするデータを導入する前に、組織体制を調整する必要があります。
| 担当者 | ニーズ | 望ましい範囲 | 再検討 |
|---|---|---|---|
| Idriss、運用 | 入力を投入しプロジェクトAを起動する | ワークスペースA、一般管理権限なし | キャンペーン終了または役割変更 |
| Noémie、検証 | 引き渡されたエクスポートを読む | 採用された結果、入力の変更なし | 検証終了 |
| Sacha、作業対応 | 許可された環境を準備する | 定義され承認された変更 | 作業完了の受領後速やかに |
アクセス票を準備し、限界を検証する
アクセス票は、人物または自動化、技術的識別情報、承認者、範囲、正当性、期限を結び付けます。秘密情報を保存することなく、公開鍵の参照情報と取り消し手順を保管してください。OpenSSHのssh-keygenでは公開鍵のフィンガープリントを表示できます。この参照情報は、秘密部分をコピーすることなく、追加や削除の際に正しい鍵を指定するのに役立ちます。
合成ファイルに対して許可された操作を試し、次に範囲外として拒否されることが想定された操作を試してください。読み取りロールの場合、開く操作は機能し、管理された変更の試みは拒否される必要があります。削除の禁止を試すために実データを使用しないでください。また、共通のパスと出力の保存先も確認してください。フォルダに対する正しい権限は、プログラムのすべてのパスを保証するものではないからです。
撤回を計画し、新たな接続を確認する
作業終了時、担当者の退任時、または侵害の疑いがある場合に撤回を実行します。責任者は、対象となるすべての認可を、同じアイデンティティに対して許可されている他のアクセス経路も含めて特定します。実際の構成に従って撤回を適用します。OpenSSHのRevokedKeysディレクティブは、文書化されている仕組みの一つに過ぎず、確認なしにマシン上で有効であると仮定してはなりません。
次に、責任者の復旧用アクセスを削除することなく、撤回されたアイデンティティでの新たな認証が拒否されることを確認します。すでに開かれているセッション、進行中のタスク、自動化用のアイデンティティを別々に検証します。認可の撤回と活動の停止は別の判断です。作業を継続する必要がある場合は、孤立したアイデンティティを残すのではなく、合意された手順に従ってその責任を移管します。
制御を妨げる近道を避ける
共通の秘密鍵は、誰が交換すべきかを不明確にし、しばしば集団でのローテーションを強いることになります。「暫定」の広範なアクセスは、誰も見直し日を定めなければ長期化しがちです。マシンの管理にも使われる検証用アカウントは、分離の制御を解釈しにくくします。これらの問題が運用上の依存になる前に、アクセス台帳で修正してください。
また、診断されていない問題を回避するためだけに、エージェント転送、トンネル、アクセスの例外を追加することも避けます。接続の必要性とその制約は、権限を持つ責任者に記述させます。本ガイドは万能なサーバー設定を提案するものではありません。仕組みは付与された権限、環境、プロジェクトの要件に依存します。一般的な文書は対象の検証には代わりません。
検証可能なままのアクセス体制を引き渡す
引き継ぎ時には、承認済みのマトリクス、有効なアイデンティティ、許可・拒否のテスト、期限、そしてアクセスを撤回できる担当者をまとめます。不在の担当者を、その秘密を拡散せずに代替できることを確認します。継続性は、プロジェクトのフォルダに共有されたパスワードではなく、手順と承認された予備の責任者によって支えられます。
引き継ぎの際には、不要になったアクセスと、個人のアイデンティティに依存する自動化を見直します。予期しない拒否が作業を妨げる場合は、技術的なアイデンティティ、対象の経路、機密を除去したエラーを含む的を絞ったインシデント記録を作成します。症状を消すためだけに一般的な権限を追加しないでください。適切な締めくくりとは、必要で、テスト済みで、既知の終了時点を伴うアクセスです。
判断のための質問
Capordiaのアカウントをすべての担当者で共有すべきですか？
いいえ。レンタルの管理と作業への技術的なアクセスは別々に整理すべきです。実際に付与される権限に基づいて、可能なマシンのアイデンティティを定義します。この方法は、Capordiaのスペースにおける招待やチームロールの仕組みを前提としていません。
公開鍵は自動的に適切な権限を与えますか？
いいえ。公開鍵は許可されている場合に認証に用いられるものであり、その後アクセス可能な操作はアカウントとシステムの権限に依存します。合成ファイルを用いて、許可されるべき操作と拒否されるべき操作を確認してください。
担当者の退任後に何を確認すべきですか？
その担当者の認可を撤回し、新たな認証が拒否されることを確認し、そのアイデンティティにまだ紐づくセッション、作業、自動化を検証します。復旧とフォローアップのために権限を持つ責任者を維持します。単なるチェックボックスだけで撤回が完了したと判断しないでください。