사람과 소프트웨어가 바뀔 때 접근 권한을 의도적으로 유지하세요.

세 가지 접근 유형을 분리하세요

예시 워크숍 위키에서 구성원은 지침을 작성하고, 노트북 코디네이터는 애플리케이션 계정을 관리하며, 호스트 유지관리자는 서버를 운영합니다. 한 사람이 둘 이상의 책임을 맡을 수 있지만 권한은 명시적으로 유지되어야 합니다. 아래 워크시트는 그룹의 의도된 정책을 설명합니다. 애플리케이션 설정은 여전히 구성하고 점검해야 합니다.

기술 관리자는 기반 데이터에 접근할 수 있을 수 있습니다. 호스트를 통제하는 사람으로부터의 프라이버시를 약속하기보다 그 책임을 그룹의 신뢰 결정에 두세요.

새 구성원에게 작고 점검된 시작 역할을 부여하세요

초대를 보내기 전에 구성원이 어떤 책을 필요로 하는지, 그리고 편집·내보내기·관리 중 무엇을 해야 하는지 합의하세요. 지원되는 경우 개별 계정을 만드세요. 의도된 범위와 변경 요청 방법을 설명하세요. 권한 누락에 대한 기본 해결책으로 관리를 부여하는 것을 피하세요.

BookStack에서는 여러 할당된 역할의 권한이 결합될 수 있으며 콘텐츠 수준 재정의가 접근에 영향을 줍니다. 전체 역할 집합과 관련 콘텐츠 규칙을 검토하세요. 역할 이름만 확인하는 것으로는 충분하지 않습니다. BookStack 역할 및 콘텐츠 권한 규칙.

1. 의도한 역할을 할당하고 소유자와 검토 트리거를 기록합니다.
2. 대표적인 비관리자 계정으로 허용된 작업을 확인합니다.
3. 읽기 전용 책을 편집하는 것처럼 실패해야 하는 작업을 확인합니다.
4. 제한된 책과 그 로컬 파일 첨부가 계속 사용 불가능한지 확인합니다.
5. 예외와 이를 승인한 사람을 기록합니다.

복구 자료를 합의된 자격 증명 저장소에 보관하세요. 접근 노트북에는 비밀번호, 토큰 또는 개인 키가 아닌 검색 참조가 들어 있습니다.

포함된 이미지를 별도로 확인하세요. BookStack 이미지는 기본적으로 공개되어 있지만 로컬 파일 첨부는 자체 권한 제어를 사용합니다. 추측하기 어려운 URL은 접근 제어가 아닙니다. BookStack 이미지 보안. 기밀을 의도한 이미지의 경우 로그아웃 상태에서 직접 URL을 테스트한 다음, 원본 페이지를 볼 수 없는 구성원으로 테스트하세요. 해당 정책에서는 어느 쪽도 이미지를 받아서는 안 됩니다.

local_secure 로그인을 요구하지만 페이지 권한을 강제하지 않으며, local_secure_restricted 이미지가 업로드된 항목에 대한 접근을 확인합니다. 스토리지를 변경하기 전에 문서화된 성능, 복사된 페이지 및 마이그레이션 제한을 검토하세요. 기존 업로드는 설정 변경만으로는 부족하며 문서화된 마이그레이션이 필요합니다. BookStack 스토리지 옵션 및 마이그레이션.

계정을 닫기 전에 인계를 마치세요

유지관리자가 떠날 때는 그 사람의 신원에 의존하는 모든 것을 파악하세요. 애플리케이션 소유권, 호스트 키, 도메인 관리, 백업 접근, 연동 및 복구 연락처가 여기에 해당합니다. 책임을 인가된 대체자에게 이전하고 그 대체자가 운영 노트를 검색할 수 있는지 확인하세요.

불필요한 애플리케이션 역할을 제거하고 각 시스템이 지원하는 제어를 통해 호스트 또는 서비스 접근을 취소하세요. 활성 세션, 토큰 및 공유 자격 증명을 별도 항목으로 검토하세요. 로그인 하나를 비활성화하면 모든 메커니즘이 취소된다고 가정하지 마세요. 떠나는 사람에게 노출된 공유 자격 증명이 있었다면 그 교체를 준비하고 사용하는 서비스를 신중히 업데이트하세요.

그룹의 정책과 애플리케이션의 동작에 따라 콘텐츠나 기여자 표시를 유지하세요. 계정 제거가 검토되지 않은 공유 작업 삭제가 되어서는 안 됩니다. 금지된 접근 확인과 업데이트된 서비스 인벤토리.

업데이트 전에 되돌리기 결정을 작성하세요

설치된 버전, 대상 버전 및 변경 이유를 기록하세요. 중간 마이그레이션과 런타임 요구 사항을 포함한 릴리스별 노트를 읽으세요. BookStack의 문서화된 업데이트 절차는 의존성과 데이터베이스를 변경할 수 있으며, 먼저 데이터베이스와 업로드의 백업을 요구합니다. BookStack 업데이트 지침.

그러한 의존성으로부터 실용적인 복구 원칙이 도출됩니다. 오래된 애플리케이션 파일을 교체하면 데이터베이스 마이그레이션이 취소될 것이라고 가정하지 마십시오. 복원할 호환 가능한 애플리케이션, 구성 및 데이터 세트를 명시하십시오. 누가 변경을 중단할 수 있는지, 그 결정은 언제 이루어져야 하는지, 그리고 복구 시점 이후에 수락된 편집은 어떻게 되는지 결정하십시오.

1. 백업의 정체성과 관련 복원 절차를 확인하십시오.
2. 가능한 경우 격리된 복사본에서 중요한 변경을 리허설하십시오.
3. 편집 일시 중지 또는 유지보수 기간을 합의하고 영향을 받는 구성원에게 알리십시오.
4. 실제 설치 방법에 대한 문서화된 업데이트를 적용하십시오.
5. 로그인, 읽기, 편집, 첨부 파일, 제한된 콘텐츠 및 구성된 작업을 확인하십시오.
6. 점검 후 일상적인 사용을 재개하거나 문서화된 복구 결정을 따르십시오.

업데이트가 실패하면 오류 증거와 현재 상태를 보존하십시오. 부분 마이그레이션 위에 관련 없는 수정 사항을 쌓지 마십시오. 애플리케이션 문서와 기록된 복구 시점을 사용하여 다음 조치를 선택하십시오.

호스트 접근을 변경할 때 작동하는 경로를 유지하세요

호스트 접근 변경은 별도의 점검이 필요합니다. 현재 승인된 SSH 세션을 열어 두고 기존 인증 경로를 제거하기 전에 새 키 기반 로그인을 확인하십시오. 새 연결이 실패할 경우 승인된 유지보수자가 어떻게 접근 권한을 되찾을지 파악하십시오.

Ubuntu OpenSSH 서버에서 문서화된 구성 검증 명령은 다음과 같습니다 sudo sshd -t. OpenSSH은 또한 다음과 같이 문서화합니다 sshd -T 유효한 설정 및 연결 매개변수를 위해 -C 일치 규칙을 평가하기 위해. 이러한 검사는 구성을 점검하며, 네트워크를 통한 성공적인 연결을 입증하지는 않습니다. Ubuntu OpenSSH 구성 점검; OpenSSH 서버 테스트 옵션.

설치된 배포판에 맞는 서비스 제어 및 구성 경로를 사용하십시오. 변경을 적용하기 전에 검증 오류를 해결하십시오. 이후 두 번째 독립 연결을 열고 유지보수에 필요한 권한을 확인하십시오. 해당 확인이 성공한 후에만 보존된 세션을 닫으십시오. 이것은 적용해야 할 변경 절차이며, 여기에서 서버 접근이 테스트되었다는 증거가 아닙니다.

노트를 업데이트할 수 있을 만큼 짧게 유지하세요

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:

그룹이 지속할 수 있는 검토 주기를 선택하고 보안 공지, 구성원 변경 또는 백업 실패를 더 빨리 조치해야 하는 이유로 간주하십시오. 운영 체제, 애플리케이션 및 통합 유지보수를 별도의 책임으로 계속 가시화하십시오. 다시 검토하십시오 복원 리허설 중대한 변경 후, 그리고 다음을 사용하십시오 공개 및 비공개 서비스 가이드 그룹이 서비스에 접근해야 하는 사람을 변경할 때.