Capordia접근 권한을 배포하기 전에 책임자 지정하기
대여 계정의 책임자, 프로젝트 접근을 승인하는 사람, 그리고 대상에 기술적 변경을 적용할 수 있는 사람을 구분하세요. 결과 책임자가 반드시 프로세스를 실행하거나 머신을 관리할 필요는 없습니다. 권한을 선택하기 전에 필요한 작업을 기록하세요: 내보내기 읽기, 입력 업로드, 작업 실행 또는 환경 수정.
그런 다음 실제로 부여된 접근의 범위를 확인하세요. ID를 생성하거나 권한을 설정할 권한이 없다면, 다른 참여자를 초대하기 전에 가능한 절차를 확인받으세요. Capordia 계정 비밀번호를 배포하여 이 제한을 우회하지 마세요. 작업 공유와 상업 계정 관리는 서로 다른 문제입니다.
개별 신원을 사용하고 그 범위를 파악하기
개별 신원을 사용하면 팀 전체의 접근 권한을 교체하지 않고도 한 사람의 접근 권한만 회수할 수 있습니다. 키 기반 SSH를 운영하는 조직에서 OpenSSH는 서버가 알고 있는 공개 키와 사용자가 보유한 개인 키를 구분합니다. 조정 문서에는 공개 키의 참조나 지문을 포함할 수 있지만, 개인 키나 그 보호 암호는 절대 포함해서는 안 됩니다.
동일한 시스템 계정에 접근할 수 있는 서로 다른 두 개의 키가 자동으로 두 개의 서로 다른 파일 범위를 만들어 주지는 않습니다. 권한은 계정과 해당 머신에 구성된 메커니즘에 따라 달라집니다. 따라서 요구 사항이 개별 인증에만 관한 것인지, 아니면 작업 분리에도 관한 것인지 결정해야 합니다. 자동화에는 동료의 개인 신원을 몰래 재사용하지 말고, 명시적인 신원과 소유자를 마련하십시오.
신원을 제시하기 전에 대상 확인하기
최초 접근 시, 접근 권한 인계 과정에서 확보한 신뢰할 수 있는 참조를 기준으로 머신 이름, 예상 계정, 그리고 그 호스트 키의 지문을 확인하십시오. 이 호스트 키는 서버를 식별하며, 사용자 키와는 별개입니다. 서버 신원 변경에 관한 예기치 않은 메시지는 알려진 참조를 자동으로 삭제할 일이 아니라 점검이 필요한 사안입니다.
OpenSSH는 호스트 키를 보관하고 그 변경을 알립니다. 이 정보를 맥락과 함께 활용하십시오. 예를 들어 머신의 재구축이 예고되었는지, 주소가 변경되었는지, 설명되지 않는 이벤트인지 등을 고려해야 합니다. 예상치 못한 변경이라면 계속 진행하기 전에 확인을 받으십시오. 목적은 접속할 때마다 의식을 추가하는 것이 아니라, 신원 경고를 단순한 표시상의 불편으로 처리하지 않는 것입니다.
가상 예시: 세 명의 담당자, 세 가지 요구
가상 팀 «Dossier des ouvrages»가 한 주간의 작업을 준비합니다. Idriss는 프로젝트 A의 처리를 실행하고, Noémie는 내보낸 결과를 검토하며, Sacha는 환경을 구성하기 위해 일시적으로 참여합니다. 팀은 표에 나온 권한을 원하지만, 실제로 인계된 시스템에서 그것이 적용 가능한지 확인해야 합니다. 이는 기존 고객 계정이나 Capordia가 발표한 팀 관리 기능에 관한 것이 아닙니다.
핵심 원칙은 Noémie가 결과를 열기 위해 관리자 접근 권한을 받지 않고, Sacha의 참여에는 끝이 있다는 것입니다. 사람의 승인만으로는 어떤 권한도 구성되지 않습니다. 기술 책임자가 사용 가능한 메커니즘을 적용하고, 그다음 각자가 정해진 점검을 수행합니다. 원하는 분리가 실현 불가능하다면, 그 분리를 요구하는 데이터를 도입하기 전에 프로젝트가 조직을 조정해야 합니다.
| 담당자 | 요구 | 목표 범위 | 재검토 |
|---|---|---|---|
| Idriss, 운영 | 입력 데이터를 올리고 프로젝트 A를 실행 | 작업 공간 A, 일반 관리 권한 없음 | 캠페인 종료 또는 역할 변경 |
| Noémie, 검증 | 인계된 결과 내보내기 읽기 | 채택된 결과, 입력 데이터 수정 없음 | 검증 종료 |
| Sacha, 참여 | 승인된 환경 준비 | 정의되고 승인된 변경 | 참여 완료 즉시 |
접근 권한 대장을 준비하고 한계를 테스트하기
대장은 사람 또는 자동화, 기술 신원, 승인자, 범위, 사유, 기한을 연결합니다. 비밀 정보는 저장하지 말고 공개 키의 참조와 회수 절차를 보관하십시오. OpenSSH ssh-keygen을 사용하면 공개 키의 지문을 표시할 수 있습니다. 이 참조는 개인 키 부분을 복사하지 않고도 추가나 삭제 시 올바른 키를 지정하는 데 도움이 됩니다.
합성 파일에서 허용된 작업을 테스트한 다음, 거부되도록 설계된 범위 밖 작업을 테스트하십시오. 읽기 역할의 경우 열기가 작동해야 하고 통제된 수정 시도가 거부되어야 합니다. 삭제 금지를 테스트할 때 실제 데이터를 사용하지 마십시오. 또한 공통 경로와 출력 대상도 확인하십시오. 폴더에 대한 올바른 권한이 프로그램의 모든 경로를 보장하지는 않기 때문입니다.
권한 회수 예정 및 새 연결 확인
작업 종료 시점, 담당자 퇴사 시점 또는 침해 의심이 있을 때 권한 회수를 실행합니다. 책임자는 해당 신원에 허용된 다른 접근 경로를 포함해 관련된 모든 권한을 파악합니다. 실제 구성에 따라 회수를 적용합니다. OpenSSH의 RevokedKeys 지시문은 문서화된 여러 메커니즘 중 하나일 뿐이며, 확인 없이 어떤 머신에서도 활성 상태라고 가정해서는 안 됩니다.
그런 다음 회수된 신원으로 새 인증이 거부되는지 확인하되, 책임자의 복구 접근 권한은 삭제하지 않습니다. 이미 열린 세션, 진행 중인 작업, 자동화 신원은 별도로 검토합니다. 권한 회수와 활동 중지는 서로 다른 결정입니다. 작업을 계속해야 한다면 고아 신원을 남기지 말고 합의된 절차에 따라 책임을 이전합니다.
통제를 방해하는 지름길 피하기
공용 개인 키를 사용하면 누가 이를 교체해야 하는지 알 수 없고, 대개 집단적 순환이 강제됩니다. "일단 임시로" 부여한 광범위한 접근은 검토 날짜를 정한 사람이 없으면 오래 지속되는 경향이 있습니다. 머신 관리를 겸하는 검증용 계정은 분리 통제를 해석하기 어렵게 만듭니다. 이러한 문제가 운영의 의존성으로 굳어지기 전에 접근 명세서에서 바로잡으십시오.
진단되지 않은 문제를 우회하기 위해서만 에이전트 전달, 터널 또는 접근 예외를 추가하는 것도 피하십시오. 연결 필요성과 제약 조건은 권한을 부여받은 책임자가 설명하도록 하십시오. 이 가이드는 보편적인 서버 구성을 제시하지 않습니다. 메커니즘은 부여된 권한, 환경, 프로젝트 요구 사항에 따라 달라집니다. 일반 문서는 대상 환경의 검증을 대신하지 못합니다.
검증 가능한 접근 체계 인계
인수 시에는 승인된 매트릭스, 활성 신원, 허용 및 거부 테스트, 기한, 그리고 접근 권한을 회수할 수 있는 담당자를 한데 모으십시오. 부재 중인 사람의 비밀을 유포하지 않고도 대체할 수 있는지 확인하십시오. 연속성은 프로젝트 폴더에 공유된 비밀번호가 아니라 절차와 권한을 부여받은 예비 책임자에 달려 있습니다.
인계 시에는 불필요해진 접근과 개인 신원에 의존하는 자동화를 다시 검토하십시오. 예기치 않은 거부로 작업이 막히면 기술 신원, 관련 경로, 정제된 오류를 담은 구체적인 장애 보고서를 작성하십시오. 증상만 없애기 위해 일반 권한을 추가하지 마십시오. 올바른 마무리는 필요하고 테스트되었으며 종료 시점이 명확한 접근입니다.
결정을 위한 질문
Capordia 계정을 모든 참여자와 공유해야 합니까?
아니요. 대여 추적과 작업에 대한 기술적 접근은 별도로 구성해야 합니다. 실제로 부여된 권한에 따라 가능한 머신 신원을 정의하십시오. 이 방법은 Capordia 공간에 초대 또는 팀 역할 시스템이 있다고 가정하지 않습니다.
공개 키가 자동으로 올바른 권한을 부여합니까?
아니요. 공개 키는 허용될 때 인증에 사용될 뿐이며, 이후 접근 가능한 작업은 계정과 시스템 권한에 따라 달라집니다. 합성 파일을 대상으로 허용되어야 할 작업과 거부되어야 할 작업을 확인하십시오.
참여자가 퇴사한 후 무엇을 확인해야 합니까?
해당 참여자의 권한을 회수하고, 새 인증이 거부되는지 확인하며, 그의 신원과 여전히 연결된 세션, 작업, 자동화를 검토하십시오. 복구와 추적을 위한 권한을 부여받은 책임자를 유지하십시오. 단순히 체크박스 하나로 회수가 완료되었다고 판단하지 마십시오.