人とソフトウェアが変わるときは、アクセスを意図的に保ちます。

3種類のアクセスを分離する

私たちの例示的なワークショップウィキでは、メンバーが指示を書き、ノートコーディネーターがアプリケーションアカウントを管理し、ホストメンテナーがサーバーを運用します。1人が複数の責任を負うこともありますが、権限は明示的に保つべきです。以下のワークシートはグループの意図するポリシーを説明しています。アプリケーション設定はまだ構成して確認する必要があります。

技術管理者は基盤データに到達できる場合があります。その責任は、ホストを制御する人からのプライバシーを約束するのではなく、グループの信頼決定に留めてください。

新メンバーには、小さく確認された開始役割を与える

招待を送る前に、メンバーがどの本を必要とし、編集、エクスポート、または何かを管理すべきかを合意します。サポートされている場合は個別のアカウントを作成します。意図した範囲と変更を要求する方法を説明し、不足している権限のデフォルトの解決策として管理を提供しないようにします。

BookStackでは、複数の割り当てられた役割が権限を結合でき、コンテンツレベルのオーバーライドがアクセスに影響します。完全な役割セットと関連するコンテンツルールを確認してください。役割の名前だけを確認するだけでは不十分です。 BookStackの役割とコンテンツ権限ルール.

1. 意図した役割を割り当て、その所有者とレビュートリガーを記録する。
2. 代表的な非管理者アカウントを使用して、許可されたタスクを確認する。
3. 読み取り専用の本の編集など、失敗するはずのタスクを確認する。
4. 制限された本とそのローカルファイル添付ファイルが利用できないままであることを確認する。
5. 例外と承認者を記録する。

復旧資料を合意された資格情報ストアに保存します。アクセスノートブックには取得参照が含まれ、パスワード、トークン、または秘密鍵は含まれません。

埋め込み画像は別途確認してください。BookStackの画像はデフォルトで公開されていますが、ローカルファイル添付ファイルはその権限制御を使用します。推測しにくいURLはアクセス制御ではありません。 BookStackの画像セキュリティ。機密を意図した画像については、サインアウト状態でその直接URLをテストし、次にそのソースページを表示できないメンバーでテストします。どちらもそのポリシーの下でそれを受け取るべきではありません。

local_secure ログインを必要としますが、ページ権限を強制しません。 local_secure_restricted 画像がアップロードされたアイテムへのアクセスをチェックします。ストレージを変更する前に、文書化されたパフォーマンス、コピーされたページ、および移行の制限を確認してください。既存のアップロードには、設定変更だけでなく、文書化された移行が必要です。 BookStackのストレージオプションと移行.

アカウントを閉じる前に引き継ぎを終える

メンテナーが退職するときは、そのIDに依存するすべてを特定します。アプリケーションの所有権、ホストキー、ドメイン管理、バックアップアクセス、統合、および復旧連絡先です。責任を承認された後任に移し、後任が運用ノートを取得できることを確認します。

不要なアプリケーション役割を削除し、各システムのサポートされている制御を通じてホストまたはサービスアクセスを取り消します。アクティブセッション、トークン、共有資格情報を別々の項目として確認し、1つのログインを無効にするとすべてのメカニズムが取り消されると仮定しないでください。退職者に共有資格情報が公開された場合は、その交換を手配し、消費サービスを意図的に更新します。

グループのポリシーとアプリケーションの動作に従って、コンテンツまたは帰属を保持します。アカウントの削除は、共有作業の未レビューの削除になってはなりません。禁止されたアクセスのチェックと更新された サービスインベントリ.

更新前に戻す決定を書く

インストールされているバージョン、意図されたバージョン、変更の理由を記録します。介入する移行とランタイム要件を含む、リリース固有のノートを読んでください。BookStackの文書化された更新プロセスは依存関係とデータベースを変更する可能性があり、最初にデータベースとアップロードのバックアップを求めています。 BookStack更新ガイダンス.

その依存関係から、実用的な復旧ルールが導かれます。古いアプリケーションファイルを置き換えればデータベースマイグレーションが元に戻ると仮定してはいけません。復元する互換性のあるアプリケーション、構成、データセットを特定してください。誰が変更を停止できるのか、その判断をいつ行う必要があるのか、復旧ポイント以降に受け入れた編集がどうなるのかを決めてください。

1. バックアップの同一性と関連する復元手順を確認します。
2. 実用的な範囲で、重要な変更を隔離されたコピー上でリハーサルします。
3. 編集の一時停止またはメンテナンス時間帯に合意し、影響を受けるメンバーに通知します。
4. 実際のインストール方法に応じた文書化された更新を適用します。
5. サインイン、閲覧、編集、添付ファイル、制限付きコンテンツ、構成済みジョブを確認します。
6. チェック後に通常利用を再開するか、文書化された復旧判断に従います。

更新が失敗した場合は、エラーの証拠と現在の状態を保全します。部分的な移行の上に無関係な修正を積み重ねるのは避けてください。アプリケーションのドキュメントと記録された復旧ポイントを使用して、次のアクションを選択します。

ホストアクセスを変更するときは、作業経路を維持する

ホストアクセスの変更は別途確認する価値があります。現在認可されている SSH セッションを開いたままにし、既存の認証経路を削除する前に新しいキーベースのログインを確認します。新しい接続が失敗した場合に、認可されたメンテナーがどのようにアクセスを取り戻すかを把握しておきます。

Ubuntu OpenSSH サーバーでは、文書化された構成検証コマンドは sudo sshd -tです。OpenSSH は以下も文書化しています sshd -T 実効設定と接続パラメータについては -C 一致ルールの評価については。これらのチェックは構成を検査するものであり、ネットワークを介した接続の成功を証明するものではありません。 Ubuntu OpenSSH 構成チェック; OpenSSH サーバーテストオプション.

インストールされているディストリビューションのサービス制御と構成パスを使用します。変更を適用する前に検証エラーを解決してください。その後、2つ目の独立した接続を開き、メンテナンスに必要な権限を検証します。そのチェックが成功した後にのみ、保全したセッションを閉じます。これは適応させるべき変更手順であり、ここでサーバーアクセスがテストされた証拠ではありません。

更新できるほど短いノートを保つ

Service / responsible maintainer / cover:
Account or change being reviewed:
Purpose / permitted tasks / forbidden tasks:
Current version / target version, if relevant:
Credential reference / recovery access reference:
Backup identifier / return decision:
Member notice or editing pause:
Checks performed / actual result:
Unresolved issue / action owner:
Next review trigger:

グループが維持できるレビューのリズムを選び、セキュリティ通知、メンバーシップの変更、バックアップの失敗を、より早く行動する理由として扱います。オペレーティングシステム、アプリケーション、統合のメンテナンスを別々の責任として可視化しておきます。再検討してください 復元リハーサル は重要な変更の後に、そして以下を使用してください パブリックおよびプライベートサービスガイド グループがサービスに到達すべき人を変更する場合に。