귀하의 질문은 플랫폼 / OS에 관한 가정을하지 않는 것 같습니다. 그렇기 때문에 "엔지니어"(질문과 같이)가 실제로 수십 명 (수백 명)의 사람들이있는 메인 프레임 환경에서이 작업이 일반적으로 수행 / 어드레싱되는 방법에 대한 답변을 추가하는 것이 합리적 일 수 있습니다. 뒤얽힌. 내 대답은 내가 가장 익숙한 SCM 제품을 사용하는 것입니다 (제품 이름을 공개 해야하는지 확실하지 않음).
1. 건축
귀하의 질문에 어떻게 대답 할 수 있는지에 대한 주요 내용은 다음과 같습니다.
- 모든 코드 (및 실행 파일과 같은 관련 아티팩트)는 파일에 저장되며이 파일은 모두 함께 라이브러리 구조 라고합니다 .
- 각 (원격의 원격) 대상 시스템의 각 환경에 대해 라이브러리 구조의 모든 항목에 대한 ALL (반복 : ALL) 업데이트를 처리하는 서버 (메인 프레임 스포크의 "시작된 작업")가 있습니다. 보안 담당자 나 공간 관리 팀과 같은 몇 가지 예외가 있지만 그 외에는 아무도 (반복 : nobody) 해당 라이브러리 구조 내의 모든 파일에 업데이트를 적용 할 권한이 없습니다. 즉 , 서버는 전체 라이브러리 구조에 대한 독점적 인 업데이트 권한을 얻습니다 . 주의 : OPS 사람들은 접근을 제한하기 위해 걸어 가면 (처음에는 저항 할 것입니다 ...) 본커 (bonker)에게 갈 것입니다.
- 실제 소프트웨어 변경 사항은 단일 구성 요소 (심야에 작은 코드 수정 ...)로 구성되거나 수백 또는 수천 개의 소스, 실행 파일 또는 기타 모든 유물 (릴리스 주말 동안) 일 수 있습니다. 그것들을 관리 가능하게 만들기 위해, 함께 (더 많거나 적은) 함께 이동 해야하는 것들이 소위 소프트웨어 변경 패키지에 묶여 있습니다 .
위와 같이 서버가 라이브러리 구조에 적용하는 모든 종류의 업데이트 는 소프트웨어 변경 패키지 (원하는 경우 SDLC) 의 수명주기 라고하는 잘 정의 된 워크 플로를 통해서만 가능합니다 . 해당 워크 플로우에서 다양한 단계를 실제로 실행하려면 다음과 같이하십시오.
- 서버 만 필수 (및 사전 구성된) 단계를 실행합니다.
- 서버는 그러한 단계를 수행하기 위해 필요한 승인 (사람으로부터)이 수집 된 후에 특정 단계 (= 라이브러리 구조의 어딘가를 업데이트) 만 수행합니다.
- 승인은 해당 승인 을 발행 할 수 있는 역할 (= 권한) 이있는 사용자 만 제공 할 수 있습니다.
2. 역할과 권한
서버는 사용자의 권한이 적절한 경우 무언가를 시도하는 사용자 (예 : '무엇인가 승인') 만 그렇게 할 수 있도록합니다. 그 부분은 쉽습니다. 그러나 SCM 시스템을 사용하여 관련된 모든 사용자에 대한 모든 권한, 즉 SCM 시스템이 아닌 보안 시스템에 속하는 모든 권한을 관리하고 싶지 않으므로 SCM 시스템에서 워크 플로우를 조정할 수 있습니다. 필요할 때마다 해당 권한을 확인하십시오. 아래 단계는 이에 대한 자세한 내용을 제공합니다.
1 단계 : 보안 시스템에서 권한 구성
보안 엔티티 에서 해당 엔티티의 이름을 잘 정의하여 보안 엔티티 를 정의하십시오 . 몇 가지 샘플 (자신의 필요에 맞게 유사한 샘플을 추가하십시오) :
PrmUnit
, 단위 테스트 를 할 수 있는 프로모션 을 요청할 수있는 권한을 얻는 데 사용됩니다 .
PrmQA
, Qa- testing 이라고 하는 프로모션 을 요청할 수있는 권한을 얻는 데 사용됩니다 (최상위 테스트라고 가정합니다).
PrdEnduser
일부 수준의 테스트에 참여한 최종 사용자가 일부 테스트에서 생성 된 결과에 만족함을 나타내는 데 사용됩니다. 그로 인해 최종 사용자는 라이브러리 구조의 변화에 동의합니다.
PrdRelmgnt
릴리스 관리자가 프로덕션 활성화 (= 라이브러리 구조의 마지막 / 가장 높은 레벨) 를 인증하는 데 사용됩니다 .
보안 시스템에서 사용자 그룹을 정의하십시오 . 몇 가지 샘플 (자신의 필요에 맞게 유사한 샘플을 추가하십시오) :
GrpDevs
는 개발자에게 해당합니다 (예 : 1 이상).
GrpEnduser
이는 최종 사용자 (적어도 1, 바람직하게는 더 유사한 사용자)에 해당합니다.
GrpRelMgnt
, 즉 릴리스 관리자 (적어도 1 명, 바람직하게는 더 많은 사용자)에 해당합니다.
선택된 " 사용자 그룹 "에 대해 선택된 " 보안 엔티티 "에 액세스 할 수 있도록 보안 시스템을 사용하여 권한을 부여 하십시오 . 위의 예를 계속하려면 다음이 적절 해 보입니다 (자신의 필요에 맞게 조정).
- 그룹
GrpDevs
은 보안 개체에 대한 액세스 권한 만 갖습니다 PrmUnit
.
- 그룹
GrpEnduser
은 보안 개체에 대한 액세스 권한 만 갖습니다 PrdEnduser
.
- 그룹
GrpRelMgnt
은 보안 개체 PrmQA
및에 액세스 할 수 PrdRelmgnt
있습니다.
2 단계 : SCM 시스템에서 워크 플로우 구성
보안 시스템에서 권한이 구성되면 (1 단계) SCM 시스템에서해야 할 일은 수명주기의 다양한 단계가 보안 시스템의 관련 보안 엔터티와 일치하는 방식을 구성하는 것입니다. 즉, 필요한 보안 엔터티에 대한 적절한 액세스 권한이있는 사용자 만 서버가 워크 플로에서 해당 단계를 수행하도록 요청할 수 있습니다.
다음은 마술을 일으키도록 SCM 시스템을 구성하는 방법에 대한 몇 가지 예입니다.
- 사용자가에 액세스 할 수있는 경우 해당 사용자는 단위 테스트 승격 을
PrmUnit
요청할 수 있습니다. 분명히 그룹 의 사용자는이 권한이 부여 된 사용자입니다 (예 : 그룹의 사용자가 아님).GrpDevs
GrpRelMgnt
- 사용자가에 액세스 할 수있는 경우 해당 사용자는 QA 테스트에
PrmQA
대한 승격 을 요청할 수 있습니다. 분명히 그룹 의 사용자는이 권한이 부여 된 사용자입니다 (예 : 그룹 또는 그룹의 사용자가 아님).GrpRelMgnt
GrpDevs
GrpEnduser
- 사용자가에 액세스 할 수있는 경우 해당 사용자는
PrdEnduser
라이브러리 구조에서 변경 사항을 진행할 수 있습니다 (일반적으로 그룹의 사용자 GrpRelMgnt
가 변경 사항을 검토 할 수 있는 전제 조건 ). 분명히 그룹의 사용자는 GrpEnduser
이 권한이 부여 된 유일한 사용자입니다.
- 사용자가에 액세스 할 수있는 경우 해당 사용자는 프로덕션 활성화 (= 라이브러리 구조의 마지막 / 가장 높은 레벨)
PrdRelmgnt
를 승인 할 수 있습니다.
3. 예기치 않은 상황을 예상하고 준비하십시오
위의 청사진은 단지 청사진이며, 결국 업무 분리를 담당하는 서버가 어떻게되는지 이해하는 데 도움이됩니다 ... CxO가 모든 사람이 좋아하지 않을 몇 가지 액세스 규칙을 적용하도록 요구하는 경우.
위에서 설명한대로 그림을 완성하기 위해 서버는 시스템에서 발생하는 모든 것에 대한 감사 추적 (로깅)을 만듭니다. 따라서 언제든지 다음과 같은 질문에 대답 할 수 있습니다.
언제, 왜 어떤 일이 일어 났으며 어떤 승인 된 사용자가 실제로 그것을 승인했는지 ...
그러나 가장 어려운 부분은 적절한보고 도구를 사용하고 사용 방법을 아는 것입니다. 최소한 IT 감사관의 요청을 (쉽게) 충족시키기 위해서는 질문이 매우 어려울 수 있습니다. 또한 SCM 시스템의 관련 로그 레코드를 가리켜 서 생산의 일부가 중단 된 위기 상황에서 모든 종류의 "무슨 일이 있었는지"에 대한 질문에 답하십시오.
추신 : 내 대답이 예 또는 DevOps 호환이 아닌 경우 모든 사람의 판단에 맡깁니다.