엔지니어가 코드를 배포하고 실행할 때 업무 분리를 가능하게하는 프로세스 또는 도구는 무엇입니까?


18

금융 서비스 부문과 같이 규제가 엄격한 환경에서 업무 분리는 개발 책임과 생산 권한이있는 개인 간의 충돌을 피하기위한 필수 메커니즘입니다.

전통적으로 이것은 개발자 가 코드를 개발 한 후이를 운영에 넘겨주는 것을 의미 했지만, 많은 DevOps 운영 모델에서는 개발과 운영의 분리가 최소한 희미 해졌습니다.

직무 분리 메커니즘의 근본 원인에 대해 몇 개월 동안 시추 한 후 Sarbanes Oxley 섹션 404 : 내부 통제 관리 평가 를 충족시키는 것이 주로 존재하는 것 같습니다 .

(a) 필수 규칙. 위원회는 1934 년 증권 거래법 13 (a) 또는 15 (d) 항에서 요구하는 각 연례 보고서에 내부 통제 보고서를 포함하도록 요구하는 규칙을 규정해야한다.

(1) 재무보고를위한 적절한 내부 통제 구조와 절차를 수립하고 유지하기위한 경영진의 책임을 명시해야합니다. 과

(2) 가장 최근의 회계 연도 말 기준으로 내부보고 구조의 효과 및 재무보고에 대한 절차의 평가에 대한 평가를 포함한다.

(b) 내부 통제 평가 및보고. (a) 항에 의해 요구되는 내부 통제 평가에서, 발행자에 대한 감사 보고서를 준비 또는 발행하는 각 등록 된 공공 회계 회사는 발행자의 관리에 의해 수행 된 평가를 입증하고보고해야한다. 이 항에 의거 한 증명은위원회가 발행 또는 채택한 증명 계약에 대한 표준에 따라 이루어져야한다. 그러한 증명은 별도의 참여의 대상이 될 수 없습니다.

의견을 바탕으로 내가 하고있는 몇 가지 가정 을 불러내는 것이 중요합니다 .

  • 저는 대량 시장 금융 서비스를 주로 고려하고 있습니다. 즉 거래량이 많지만 상대적으로 가치가 낮습니다. 이는 거래 가치 프로필이 다른 상업용 금융 서비스와 반대입니다.
  • 금융 기관의 온라인 서비스는 다음과 같은 다양한 위험 요소를 고려한 여러 구성 요소로 구성됩니다.
    • 돈 이동 -계정 간 이동 또는 다른 소유자의 계정 간 이동. 자금 세탁 방지, 사기 방지 및 수출 금지 국가를 고려해야하는 작업.
    • 고객 확보 -Move Money에 비해 거래량이 적지 만 여전히 고려해야 할 "Risky"가 적습니다.
    • 인터넷 뱅킹 -다양한 수준의 위험이있는 광범위한 서비스를 다루며, Move Money는이 중 일부로 간주됩니다.
  • 위험에 따라 각각 다른 접근 방식을 취할 수는 있지만, 단순성을 유지하기 위해 가장 위험한 작업에 적용 할 수있는 솔루션을 찾고 있습니다.

TL; DR : 증권 거래위원회의 규정 을 준수하는 적절한 내부 통제가 이루어 지도록하는 것은 경영진의 책임입니다 .

Sarbanes Oxley 404는 일반적으로 하향식 위험 평가 (Top-Down Risk Assessment)를 완료함으로써 만족되며,이 중 일부는 공모 위험을 평가하고 완화 전략을 제시합니다.

개발자가 일상적으로 소스 제어 및 프로덕션에 모두 액세스 할 수있는 DevOps 실습 및 문화를 사용하는 회사 내에서 업무 분리를 달성하는 방법 또는보다 일반적으로 담합 위험을 완화 할 수있는 방법.


개발팀 조직의 주요 아이디어는 팀의 모든 구성원이 생산 과정에서 발생하는 일에 대해 책임을 지도록해야한다는 것입니다. 이는 주로 이러한 분리에 대한 규제 요구가있을 때 이러한 종류의 조직을 실제로 사용할 수 없음을 의미합니다.
Tensibai

@ Tensbai 나는 DevOps가 의무 분리와 호환되지 않는다는 주장에 기본적으로 동의하지 않습니다. 법률은 통제 방식에 대해 규범이 아니며 규제 기관이 은행 및 금융 서비스에 사전 정의 된 프로세스를 부과하지도 않습니다. 규제 기관과 임명 된 감사인에게 적절한 것이 무엇인지, 그리고 완전히 투명한지 확인하는 것은 조직에 달려 있습니다. 예를 들어 ING과 Barclays는 DevOps 사례를 채택하여 고객에게 가치를 제공하는 능력을 가속화 할 수있었습니다.
Richard Slater

그렇습니다. 규제 분리에 국한되지 않은 주제에 대한 전문가들은 제한적인 주제 (실제로 소수)에 대해 전통적인 사일로 기반 조직에서 자동화를 활용했습니다. 소프트웨어가 어떤 종류의 작업을 수행 하느냐에 따라 두 종류의 조직이 있습니다.
Tensibai

"규제 분리"와 같은 법령 / 법률 및 규제 기관은 금융 기관에 대한 분리를 강요하지 않으며 재무 위험을 관리하기 위해 "적절한 통제"를 갖는 관리 책임을 부과합니다. Agile이 소프트웨어 개발을 긴주기에서 작은 주기로 수행 한 것과 마찬가지로 DevOps는 작업을 작은 주기로 수행하고, 금융 서비스의 DevOps는 예를 들어 CD 파이프 라인을 작성하여 업무 분리를 작은 주기로 전환하는 방법을 찾아야합니다. 동료 검토 및 승인 기반 승격과 같은 "적절한 통제"를 시행합니다.
Richard Slater

1
@ Pierre.Vriens 네, 광범위한 질문이 제목에 있습니다. 나는 몇 가지 가정을 통해 그것을 확장하려고 노력했습니다. Break-Glass 및 Privileged Account Management와 같은 역할이 솔루션의 일부일 수 있습니다. 역할 및 책임은 DevOps / Agile에서 흥미로운 개념으로, Java 개발자, F / E 개발자, 디자이너, PM, 빌드 엔지니어, 릴리스 관리자 및 Ops 엔지니어가 있었을 때와 같이 흥미로운 개념이되었습니다. 여러 모자를 착용하십시오. 전문 엔지니어이지만 책임을 공유 할 수있는 "엔지니어"로 구성된 부서 간 팀.
Richard Slater

답변:


8

귀하의 질문은 플랫폼 / 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요청할 수 있습니다. 분명히 그룹 의 사용자는이 권한이 부여 된 사용자입니다 (예 : 그룹의 사용자가 아님).GrpDevsGrpRelMgnt
  • 사용자가에 액세스 할 수있는 경우 해당 사용자는 QA 테스트에 PrmQA대한 승격 을 요청할 수 있습니다. 분명히 그룹 의 사용자는이 권한이 부여 된 사용자입니다 (예 : 그룹 또는 그룹의 사용자가 아님).GrpRelMgntGrpDevsGrpEnduser
  • 사용자가에 액세스 할 수있는 경우 해당 사용자는 PrdEnduser라이브러리 구조에서 변경 사항을 진행할 수 있습니다 (일반적으로 그룹의 사용자 GrpRelMgnt가 변경 사항을 검토 할 수 있는 전제 조건 ). 분명히 그룹의 사용자는 GrpEnduser이 권한이 부여 된 유일한 사용자입니다.
  • 사용자가에 액세스 할 수있는 경우 해당 사용자는 프로덕션 활성화 (= 라이브러리 구조의 마지막 / 가장 높은 레벨) PrdRelmgnt를 승인 할 수 있습니다.


3. 예기치 않은 상황을 예상하고 준비하십시오


위의 청사진은 단지 청사진이며, 결국 업무 분리를 담당하는 서버가 어떻게되는지 이해하는 데 도움이됩니다 ... CxO가 모든 사람이 좋아하지 않을 몇 가지 액세스 규칙을 적용하도록 요구하는 경우.

위에서 설명한대로 그림을 완성하기 위해 서버는 시스템에서 발생하는 모든 것에 대한 감사 추적 (로깅)을 만듭니다. 따라서 언제든지 다음과 같은 질문에 대답 할 수 있습니다.

언제, 왜 어떤 일이 일어 났으며 어떤 승인 된 사용자가 실제로 그것을 승인했는지 ...

그러나 가장 어려운 부분은 적절한보고 도구를 사용하고 사용 방법을 아는 것입니다. 최소한 IT 감사관의 요청을 (쉽게) 충족시키기 위해서는 질문이 매우 어려울 수 있습니다. 또한 SCM 시스템의 관련 로그 레코드를 가리켜 서 생산의 일부가 중단 된 위기 상황에서 모든 종류의 "무슨 일이 있었는지"에 대한 질문에 답하십시오.


추신 : 내 대답이 예 또는 DevOps 호환이 아닌 경우 모든 사람의 판단에 맡깁니다.


이는 하향식 위험 평가의 기본 구현처럼 들리지만, 개발자가 '배치'스위치를 트리거 할 권한이있는 devops 방식으로 이것이 어떻게 구현 될 수 있는지에 대한 질문을 어떻게 해결할 수 있는지 모르겠습니다. devops 조직에서 할 수 없다는 생각입니까?
Tensibai

@Tensibai "if"개발자는 (예를 들어, 일반적으로 그러한 조직에는없는) prod에 대한 최종 승인의 승인 (역할)을 갖게되며, 그런 다음 서버 (시작된 작업)는 배포를 시작합니다. 그리고 질문의 제목에 따라 이것이 "a"가능한 대답이라고 생각합니다. 그러나 이것이 우리가 DevOps 조직이라고 부르는 것인지 의문을 제기 할 수는 있지만, 감사인이 이런 종류의 "구성 가능한"직무 분리 (예 : 사안 및 변형)를 정말 좋아한다는 것을 알고 있습니다. 아마도 Richard는 이것에 대한 그의 견해로 우리를 도울 수 있습니까?
Pierre.Vriens

1
나는 감사인이 절대적으로 그것을 좋아한다는 것에 동의한다. 나는 이것이 접근의 '폭발'과 어떻게 관련이 있는지를 놓쳤다. 감사인은 목록에 6-7 명 이상이 포함되어있을 때 일반적으로 싫어한다. 적합하지 않다고 말하는 것은 절대적으로 유효한 대답 IMHO입니다.
Tensibai

1
많은 시간을 답변 해 주셔서 감사합니다. 실제로 3 인 규칙을 구현하려고합니다. 한 개발자가 코드를 작성하고 다른 개발자가 코드를 검토하고 다른 사람이 릴리스 버튼을 눌러 코드를 배포한다는 점입니다. 다른 고려 사항은 개발 팀이 매우 작은 회사 전체의 Agile / DevOps 채택의 일부이기 때문에 소규모 그룹의 생산이 얇은 생산 조각에 액세스 할 수있는 순 효과로 인해 위험 관점에서 유리한 것 같습니다. .
Richard Slater

1
@ Pierre.Vriens 두 번 공감 할 수 없습니다, 훌륭한 확장 :)
Tensibai

5

프랑스어 "내부 통제"규정에 대한 나의 지식, 당신이 가리키는 SEC 규정과 같은 종류의 지식에 근거한 대답, 나는 여기에 프랑스 법률 텍스트에 링크하는 것이 실제로 유용하지 않을 것이라고 가정하고 그것을 잘 번역하지 못한다는 것을 알고 있습니다.

이상적인 'You build it, you it'모델에서는 팀의 모든 사람이 변경에 대한 책임을집니다. 위험 평가는 직무 분리로 시행 할 수 없으며 규정을 준수하는 것으로 알고있는 유일한 방법은 릴리스를 한 사람에게 다시 연락하기 위해 변경 불가능한 조치 추적과 함께 트랜잭션에 대한주기적인 짧은주기 감사를하는 것입니다. .
즉, 모든 거래 및 조치 로그는 팀이 액세스 할 수없는 제한된 영역으로 푸시됩니다. "로그"된 내용의 변경 사항은 팀이 액세스 할 수없고 기능 상태 테스트에 의해 포착되어야 함을 의미합니다. 감사하여 작성자에게 추적합니다.

프랑스에서 서면으로 돈을 송출 할 수있는 회사 (주로 은행)가 모든 상품에 적용되는 것은 아니며 모든 거래가 기록되어 거래가 누락 될 위험을 감수하지 않아야합니다.
반면에, 누군가가 대출을 요청할 때 상업적 제안 또는 위험 평가를 추적 할 법적 의무가 없으므로,이 고객 선택을 처리하고 제안에 포함될 수수료를 계산하는 제품은 포스트에 맞추기가 더 쉽습니다. 릴리스 감사 모델.

주요 아이디어는 위험 평가 의무에 따라 릴리스 모델을 조정해야한다는 것입니다.

관련 리소스는 ISO27001 표준입니다.


많은 유럽 은행들이 실제로 프랑스에서 운영하는 것처럼 흥미로운 답변과 매우 관련이 있습니다. 'Emit Money'가 의미하는 바를 확장 할 수있는 가능성이 있습니까? 즉, ATM에서 현금으로 현금을 인출하거나 잔액 이체를 포함하는 것입니다. 이 경우 법령과의 연결은 해당 언어에 관계없이 관련 법률에 대한 지침을 제공하므로 가치가 있습니다.
Richard Slater

@RichardSlater 간단히 말해, 돈을 사용하는 회사는 전통적인 은행을 따라 투자 중개인이자 대출 중개인이 될 수 있습니다. 대부분 어딘가에 재정적 영향을 미치는 모든 것이 우려된다 (당국이 상황에 따라 줄 수있는 예외는 거의 없다). 프랑스어로 된 법적 "목록"은 여기 있지만 프랑스어로도 항상 명확하지는 않습니다.
Tensibai

나는 ISO 표준에 대한 링크가 실제로해야한다고 가정하고 있어요 2013 : ISO27001
리차드 슬레이터

@Richard는 실제로 Wikipedia에서 French to English 링크가 업데이트되지 않은 것 같습니다. 나중에 업데이트하겠습니다 (또는 원하는 경우 자유롭게 편집).
Tensibai


0

IMHO, 개발자 및 운영은 고유 한 권한 모델을 사용 하여 동일한 코드베이스에 대해 두 개의 git 저장소로 나타낼 수 있으므로 팀은 서로의 작업을 전혀 방해하지 않습니다.

예를 들어 Dev.mygithub.co & ops.mygithub.co 라고하겠습니다 .

아이디어는 개발자가 -git 전체 추적을 제공하고 자신의 마음의 콘텐츠에 / 분기 / 병합을 만들 무료이며 그 규제 프레임 워크를 검토 노력을 의미하는 순간에, 여기 - 한편 중요한 일이라고한다 풀 요청이 들어 올릴 수있다 합병은 통제 된 방식으로 발생합니다.

이 개념을 다음 단계로 끌어 올리면 개발 지점을 또 다른 Pull Request 행위 를 통해 원격 Ops의 프로덕션 으로 전파 할 수 있습니다 . 마지막 부분은 운영 팀의 손과 눈으로 발생해야합니다. 프로덕션 환경에서이를 조사 할 책임이 있고 검토 수준을 선택하기 때문입니다.

이러한 체계는 무한한 유연성, 완벽한 추적 성, 다양한 프로세스를 통해 조기에 문제를 포착하는 능력, 우려의 분리 및 프로세스의 매우 합리적인 사용자 경험을 허용합니다 !

NB Ops & Dev가 완전히 겹친 경우에도 위에서 설명한 모델을 따를 수 있습니다!


1
당연히, 이와 동일한 제어는 풀 요청과 커밋 후 후크를 통해 달성 될 수 있습니다. 개발자는 자유롭게 커밋 할 수 있지만 승인 된 그룹 만 병합 커밋을 수행 할 수 있습니다. 마찬가지로, 동일한 커밋 후 후크가 풀 요청을 구성한 커밋의 작성자가 풀 요청을하는 사람을 포함하지 않도록 할 수 있습니다.
Richard Slater

@RichardSlater : 두 개의 개별 리포지토리를 원할 수있는 이유 는 개발자 모드에서 코드를 자유롭게 교환 할 때 개발자가 병합 할 수 있어야하며 대부분의 개발자가 코드를 병합하지 못하도록 차단 해야하기 때문입니다. 생산 (모듈로 SysOps, 즉 "승인 된 승인 된 그룹")으로 이동합니다.
fgeorgatos

다시 한 번 커밋 후 후크 및 풀 요청으로 GitHub Enterprise가 보호 된 브랜치를 허용한다는 것을 알 수 있습니다.
Richard Slater

0

높을수록 더 비쌉니다.

  • 서로 다른 작업을 수행하는 고유 한 개발 및 운영 사이트 및 방법
  • 위와 같이 뚜렷한 개발 및 운영 시스템 및 방법
  • 뚜렷한 개발 및 운영 git / vcs 저장소 및 관련 방법
  • 뚜렷한 개발 및 운영 git / vcs 브랜치 (보호) 및 관련 방법

수행 한 작업에 따라 일부 솔루션이 다른 솔루션보다 낫습니다. 예를 들어, 팀 내에서 고유 한 역할을 가진 두 팀에 서비스를 제공해야하고 각 팀에 소유권이 있고 완전한 추적 성을 제공해야하는 경우 처음 3 개 이상을 가리키고 있습니다.

요컨대, 한 남자 또는 여자가 공을 단독으로 가지고 다닐 수 없으며, dev와 op 사이의 명확한 경계를 넘나 드는 것을 강제하는 것은 무엇이든 가능합니다. 이제 위험 수준에 따라 해당 경계가 시행 될 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.