DevOps와 DevSecOps: 한 은행의 모습

은행은 프로젝트를 많은 계약자에게 아웃소싱합니다. "외부"는 코드를 작성한 다음 그다지 편리하지 않은 형식으로 결과를 전송합니다. 구체적으로 프로세스는 다음과 같습니다. 기능 테스트를 통과한 프로젝트를 넘겨준 다음 은행 경계 내부에서 통합, 로드 등에 대한 테스트를 거쳤습니다. 테스트가 실패하는 경우가 종종 발견되었습니다. 그런 다음 모든 것이 외부 개발자에게 돌아갔습니다. 짐작할 수 있듯이 이는 버그 수정에 긴 리드 타임을 의미했습니다.

은행은 커밋에서 릴리스까지 전체 파이프라인을 자체 관리 아래로 끌어들이는 것이 가능하고 필요하다고 결정했습니다. 모든 것이 통일되고 은행의 제품을 담당하는 팀의 통제를 받게 됩니다. 즉, 마치 외부 계약자가 단순히 사무실 옆방 어딘가에서 일하고 있는 것처럼 보입니다. 기업 스택에서. 이것은 일반적인 데브옵스입니다.

Sec는 어디서 왔나요? 은행의 보안은 외부 계약자가 네트워크 부문에서 작업하는 방법, 누군가의 액세스 권한, 코드 작업 방법 및 대상에 대해 높은 요구 사항을 제시했습니다. 다만 IB는 계약업체가 외부에서 일할 때 은행 기준을 거의 따르지 않는다는 사실을 아직 몰랐습니다. 그리고 며칠 안에 모두가 관찰을 시작해야 합니다.

계약자가 제품 코드에 대한 전체 액세스 권한을 갖고 있다는 단순한 사실이 이미 그들의 세상을 뒤집어 놓았습니다.

이 순간 제가 여러분께 들려드리고 싶은 DevSecOps의 이야기가 시작되었습니다.

이 상황에서 은행은 어떤 실질적인 결론을 이끌어냈습니까?

모든 일이 잘못된 방식으로 이뤄지고 있다는 점을 두고 많은 논란이 일었다. 개발자들은 보안이 개발을 방해하려고만 바빠서 파수꾼처럼 생각 없이 금지하려고 한다고 말했습니다. 결과적으로 보안 전문가들은 "개발자가 우리 회로에 취약점을 생성합니다"와 "개발자가 취약점을 생성하는 것이 아니라 개발자 자신입니다"라는 관점 중에서 선택하는 것을 망설였습니다. 새로운 시장 수요와 DevSecOps 패러다임의 출현이 아니었다면 논쟁은 오랫동안 계속되었을 것입니다. 정보 보안 요구 사항을 "기본적으로" 고려한 프로세스 자동화가 모든 사람을 행복하게 유지하는 데 도움이 될 것이라고 설명하는 것이 가능했습니다. 규칙은 즉시 기록되고 게임 중에 변경되지 않는다는 의미에서(정보 보안은 예상치 못한 일을 금지하지 않음), 개발자는 발생하는 모든 일에 대해 정보 보안에 정보를 유지합니다(정보 보안은 갑자기 어떤 일이 발생하지 않음). . 각 팀은 추상적인 형이 아닌 궁극적인 안전을 책임집니다.

1. 외부 직원은 이미 코드와 여러 내부 시스템에 접근할 수 있기 때문에 “개발은 전적으로 은행 인프라에서 수행되어야 한다”는 요구 사항을 문서에서 삭제하는 것이 가능할 것입니다.
2. 반면에, 우리는 현재 일어나고 있는 일에 대한 통제력을 강화해야 합니다.
3. 타협점은 직원들이 외부 사람들과 긴밀하게 협력하는 다기능 팀을 만드는 것이었습니다. 이 경우 팀이 은행 서버의 도구를 작업하는지 확인해야 합니다. 처음부터 끝까지.

즉, 계약업체의 입주는 허용되지만 별도의 세그먼트를 제공해야 합니다. 외부에서 은행 인프라로 어떤 종류의 감염을 가져오지 않고 필요한 것 이상을 보지 않도록 하기 위해서입니다. 글쎄, 그들의 행동이 기록되도록. 누출 방지를 위한 DLP, 이 모든 것이 포함되었습니다.

원칙적으로 모든 은행은 조만간 이에 도달합니다. 여기에서 우리는 익숙한 길을 따라 "외부"가 작동하는 환경에 대한 요구 사항에 동의했습니다. 최대 범위의 액세스 제어 도구, 취약성 검사 도구, 회로, 어셈블리 및 테스트에 대한 바이러스 백신 분석이 나타났습니다. 이를 DevSecOps라고 합니다.

DevSecOps 이전에는 은행 보안이 개발자 측에서 발생하는 일을 제어할 수 없었다면 새로운 패러다임에서는 보안이 인프라의 일반 이벤트와 동일한 방식으로 제어된다는 것이 갑자기 분명해졌습니다. 지금은 어셈블리, 라이브러리 제어 등에 대한 경고가 있습니다.

남은 것은 팀을 새 모델로 이전하는 것뿐입니다. 글쎄, 인프라를 만드십시오. 하지만 이것은 사소한 일입니다. 마치 올빼미를 그리는 것과 같습니다. 실제로 우리는 인프라 구축을 도왔고 당시 개발 프로세스가 바뀌고 있었습니다.

무엇이 바뀌었나요?

우리는 많은 프로세스가 무너지고 많은 "외부인"이 모든 사람의 감독하에 있는 새로운 작업 조건을 견디지 못할 수 있다는 것을 이해했기 때문에 이를 작은 단계로 구현하기로 결정했습니다.

먼저, 우리는 다기능 팀을 만들고 새로운 요구 사항을 고려하여 프로젝트를 구성하는 방법을 배웠습니다. 조직적으로 어떤 프로세스가 있는지 논의했습니다. 그 결과 모든 책임자가 포함된 조립 파이프라인의 다이어그램이 탄생했습니다.

• CI : Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• 테스트 : Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• 발표자: (보고, 커뮤니케이션): Grafana, Kibana, Jira, Confluence, RocketChat.
• 행정부 (유지보수, 관리): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

선택한 스택:

• 기술 자료 - Atlassian Confluence;
• 작업 추적기 - Atlassian Jira;
• 아티팩트 저장소 - "Nexus";
• 지속적인 통합 시스템 - “Gitlab CI”;
• 지속적인 분석 시스템 - “SonarQube”;
• 애플리케이션 보안 분석 시스템 - "Micro Focus Fortify";
• 통신 시스템 - "GitLab Mattermost";
• 구성 관리 시스템 - "Ansible";
• 모니터링 시스템 - “ELK”, “TICK Stack”(“InfluxData”).

그들은 계약자를 내부로 끌어들일 준비가 된 팀을 만들기 시작했습니다. 몇 가지 중요한 사항이 있다는 것을 깨달았습니다.

• 적어도 코드를 전송할 때는 모든 것이 통합되어야 합니다. 왜냐하면 계약자가 많은 만큼 각자의 특성을 지닌 다양한 개발 프로세스가 있었기 때문입니다. 모든 사람을 대략적으로 하나에 맞추는 것이 필요했지만 옵션이 포함되었습니다.
• 계약자가 많고 인프라를 수동으로 생성하는 것은 적합하지 않습니다. 새로운 작업은 매우 빠르게 시작되어야 합니다. 즉, 개발자가 파이프라인을 관리할 수 있는 솔루션 세트를 확보할 수 있도록 인스턴스가 거의 즉시 배포되어야 합니다.

첫 번째 단계를 수행하려면 현재 진행 중인 작업을 이해하는 것이 필요했습니다. 그리고 우리는 거기까지 가는 방법을 결정해야 했습니다. 우리는 인프라와 CI/CD 자동화 모두에서 대상 솔루션의 아키텍처를 그리는 것을 돕는 것부터 시작했습니다. 그런 다음 우리는 이 컨베이어를 조립하기 시작했습니다. 우리는 동일한 컨베이어가 작동하는 모든 사람에게 동일한 하나의 인프라가 필요했습니다. 우리는 계산 옵션을 제공했다고 은행은 생각한 다음 무엇을 건설하고 어떤 자금을 사용할지 결정했습니다.

다음은 회로 생성-소프트웨어 설치, 구성입니다. 인프라 배포 및 관리를 위한 스크립트 개발. 다음은 컨베이어 지원으로의 전환입니다.

우리는 파일럿에서 모든 것을 테스트하기로 결정했습니다. 흥미롭게도, 시범 운영 중에 처음으로 은행에 특정 스택이 나타났습니다. 무엇보다도 신속한 출시를 위한 파일럿 범위로 솔루션 중 하나를 공급하는 국내 공급업체가 제안되었습니다. 그가 조종하는 동안 보안요원은 그를 알게 되었고, 이는 잊을 수 없는 인상을 남겼습니다. 다행히 전환을 결정했을 때 인프라 계층은 이전에 이미 은행에 있던 Nutanix 솔루션으로 교체되었습니다. 게다가 이전에는 VDI용이었는데, 인프라 서비스용으로 재사용했습니다. 소량에서는 경제에 적합하지 않았지만 대량으로 개발 및 테스트하기에 탁월한 환경이 되었습니다.

스택의 나머지 부분은 모든 사람에게 어느 정도 친숙합니다. Ansible의 자동화 도구가 사용되었으며 보안 전문가가 이들과 긴밀하게 협력했습니다. Atlassin 스택은 프로젝트 이전에 은행에서 사용되었습니다. Fortinet 보안 도구 - 보안 담당자가 직접 제안한 도구입니다. 테스트 프레임은 은행에서 만들었으며 질문은 없습니다. 저장소 시스템이 의문을 제기했기 때문에 익숙해져야 했습니다.

계약자에게 새로운 스택이 주어졌습니다. GitlabCI용으로 다시 작성하고 Jira를 뱅킹 부문으로 마이그레이션하는 등의 작업을 수행할 시간을 주었습니다.

단계별로

1 단계. 첫째, 국내 공급업체의 솔루션을 사용했으며 해당 제품은 새로 생성된 DSO 네트워크 세그먼트에 연결되었습니다. 이 플랫폼은 배송 시간, 확장 유연성 및 완전 자동화 가능성 때문에 선택되었습니다. 실시된 테스트:

• 가상화 플랫폼 인프라(네트워크, 디스크 하위 시스템, 컴퓨팅 리소스 하위 시스템)의 유연하고 완전 자동화된 관리 가능성.
• 가상 머신 수명주기 관리 자동화(템플릿 작성, 스냅샷, 백업)

플랫폼 설치 및 기본 구성 후 두 번째 단계 하위 시스템(DSO 도구, 소매 시스템 개발 개요)의 배치 지점으로 사용되었습니다. 가상 머신의 생성, 삭제, 수정, 백업 등 필요한 파이프라인 세트가 생성되었습니다. 이러한 파이프라인은 배포 프로세스의 첫 번째 단계로 사용되었습니다.

결과적으로 제공된 장비는 은행의 성능 및 내결함성 요구 사항을 충족하지 못합니다. 은행의 DIT는 Nutanix 소프트웨어 패키지를 기반으로 컴플렉스를 만들기로 결정했습니다.

단계 2. 우리는 정의된 스택을 가져와 모든 하위 시스템에 대해 자동화된 설치 및 구성 후 스크립트를 작성하여 모든 것이 파일럿 회로에서 대상 회로로 최대한 빨리 전송되도록 했습니다. 모든 시스템은 내결함성 구성(이 기능은 공급업체의 라이선스 정책에 의해 제한되지 않음)으로 배포되었으며 메트릭 및 이벤트 수집 하위 시스템에 연결되었습니다. IB는 요구 사항 준수 여부를 분석하고 승인했습니다.

단계 3. 모든 하위 시스템과 해당 설정을 새 PAC로 마이그레이션합니다. 인프라 자동화 스크립트가 다시 작성되었으며 DSO 하위 시스템의 마이그레이션이 완전 자동화 모드에서 완료되었습니다. IP 개발의 윤곽은 개발팀의 파이프라인에 의해 재현되었습니다.

4 단계. 응용프로그램 소프트웨어 설치 자동화. 이러한 작업은 새 팀의 팀 리더가 설정했습니다.

5 단계. 착취.

원격 액세스

개발팀은 회로 작업 시 최대한의 유연성을 요구했으며, 프로젝트 초기부터 개인 노트북을 통한 원격 액세스에 대한 요구 사항이 제기되었습니다. 은행에는 이미 원격 액세스가 있었지만 개발자에게는 적합하지 않았습니다. 사실 이 체계는 보호된 VDI에 대한 사용자 연결을 사용했습니다. 이는 직장에서 우편물과 사무실 패키지만 필요한 사람들에게 적합했습니다. 개발자에게는 많은 리소스가 포함된 헤비 클라이언트, 고성능이 필요합니다. 물론 VStudio(예를 들어)나 다른 SDK로 작업하는 사용자의 사용자 세션 손실은 허용되지 않기 때문에 정적이어야 했습니다. 모든 개발 팀을 위해 다수의 Thick Static VDI를 구성하면 기존 VDI 솔루션의 비용이 크게 증가했습니다.

우리는 개발 부문의 리소스에 직접 원격 액세스하는 작업을 수행하기로 결정했습니다. Jira, Wiki, Gitlab, Nexus, 빌드 및 테스트 벤치, 가상 인프라. 경비원은 다음 조건에 따라서만 접근 권한을 제공할 것을 요구했습니다.

1. 은행에서 이미 사용 가능한 기술을 사용합니다.
2. 인프라에서는 생산 계정 개체의 레코드를 저장하는 기존 도메인 컨트롤러를 사용해서는 안 됩니다.
3. 액세스는 특정 팀에 필요한 리소스로만 제한되어야 합니다(한 제품 팀이 다른 팀의 리소스에 액세스할 수 없도록).
4. 시스템의 RBAC에 대한 최대 제어.

결과적으로 이 세그먼트에 대해 별도의 도메인이 생성되었습니다. 이 도메인에는 사용자 자격 증명과 인프라를 비롯한 모든 개발 부문 리소스가 포함되어 있습니다. 이 도메인의 레코드 수명주기는 은행에 존재하는 IdM을 사용하여 관리됩니다.

직접 원격 액세스는 은행의 기존 장비를 기반으로 구성되었습니다. 액세스 제어는 컨텍스트에 대한 규칙이 일치하는 AD 그룹으로 나누어졌습니다(제품 그룹 XNUMX개 = 규칙 XNUMX개 그룹).

VM 템플릿 관리

환경 준비 속도는 파이프라인의 전체 실행 시간에 직접적인 영향을 미치기 때문에 어셈블리 및 테스트 루프 생성 속도는 개발 부서 책임자가 설정하는 주요 KPI 중 하나입니다. 기본 VM 이미지를 준비하기 위한 두 가지 옵션이 고려되었습니다. 첫 번째는 최소 이미지 크기, 모든 시스템 제품의 기본값, 설정과 관련된 은행 정책의 최대 준수입니다. 두 번째는 기본 이미지로, 설치 시간이 파이프라인 실행 속도에 큰 영향을 미칠 수 있는 강력한 POPPO가 포함되어 있습니다.

개발 과정에서 인프라 및 보안 요구 사항도 고려되었습니다. 이미지를 최신 상태로 유지(패치 등)하고, SIEM과 통합하고, 은행 표준에 따른 보안 설정을 수행했습니다.

결과적으로 최신 상태를 유지하는 데 드는 비용을 최소화하기 위해 최소한의 이미지를 사용하기로 결정했습니다. 새 버전의 POPPO에 맞게 각 이미지를 패치하는 것보다 기본 OS를 업데이트하는 것이 훨씬 쉽습니다.

결과를 바탕으로 최소한 필요한 운영 체제 세트로 목록이 구성되었으며 업데이트는 운영 팀에서 수행되었으며 파이프라인의 스크립트는 소프트웨어 업데이트를 전적으로 담당하고 필요한 경우 버전을 변경합니다. 설치된 소프트웨어 - 필요한 태그를 파이프라인으로 전송하기만 하면 됩니다. 예, 이를 위해서는 DevOps 제품 팀이 더 복잡한 배포 시나리오를 가져야 하지만 기본 이미지를 지원하는 데 필요한 운영 시간이 크게 단축됩니다. 그렇지 않으면 유지 관리하는 데 XNUMX개가 넘는 기본 VM 이미지가 필요할 수 있습니다.

인터넷 접속

뱅킹 보안의 또 다른 걸림돌은 개발 환경에서 인터넷 리소스에 액세스하는 것이었습니다. 또한 이 액세스는 두 가지 범주로 나눌 수 있습니다.

1. 인프라 접근.
2. 개발자 액세스.

인프라 액세스는 Nexus를 사용하여 외부 저장소를 프록시하여 구성되었습니다. 즉, 가상 머신에서 직접 액세스가 제공되지 않았습니다. 이를 통해 개발 부문에서 외부 세계에 대한 액세스를 제공하는 것을 절대적으로 반대하는 정보 보안과의 타협이 가능해졌습니다.

개발자는 분명한 이유로 인터넷에 액세스해야 했습니다(스택오버플로우). 그리고 위에서 언급한 대로 모든 명령이 회로에 원격으로 액세스할 수 있었지만 IDE 은행에 있는 개발자 작업장에서 Ctrl+V를 수행할 수 없는 경우 항상 편리한 것은 아닙니다.

처음에는 테스트 단계에서 화이트리스트에 따라 은행 프록시를 통해 액세스가 제공된다는 합의가 IS와 이루어졌습니다. 프로젝트가 완료되면 액세스 권한이 블랙리스트로 이전됩니다. 프로젝트 시작 시 액세스가 필요한 주요 리소스와 저장소를 나타내는 거대한 액세스 테이블이 준비되었습니다. 이러한 액세스를 조정하는 데 상당한 시간이 걸렸기 때문에 블랙리스트로의 가장 빠른 전환을 주장할 수 있었습니다.

조사 결과

이 프로젝트는 XNUMX년도 채 지나지 않아 끝났습니다. 이상하게도 모든 계약자는 적시에 새로운 스택으로 전환했고 새로운 자동화로 인해 아무도 남지 않았습니다. IB는 긍정적인 피드백을 공유하기 위해 서두르지 않지만 불평하지도 않습니다. 이를 통해 그들이 좋아한다고 결론을 내릴 수 있습니다. 정보 보안이 다시 통제되고 있다고 느껴지지만 개발 프로세스를 방해하지 않기 때문에 갈등이 가라앉았습니다. 팀에 더 많은 책임이 주어졌고 정보 보안에 대한 전반적인 태도가 더 좋아졌습니다. 은행은 DevSecOps로의 전환이 거의 불가피하다는 것을 이해했으며 제 생각에는 가장 온화하고 올바른 방식으로 전환했습니다.

알렉산더 슈빈(Alexander Shubin), 시스템 설계자.

출처 : habr.com