DevOps에서 보안을 전환한다는 것은 사고방식을 전환한다는 것을 의미합니다.

아주 오래전, 제가 어리석은 젊은 UNIX 시스템 관리자였을 때(지금은 그 중 한 사람일 뿐입니다) 백업 시스템을 운영하는 서버 중 하나에서 심각한 보안 실수를 저질렀습니다. 자세한 내용은 언급하지 않겠지만, sudo 명령, 텍스트 편집기, 그리고 무지함이 원인이었습니다.

다행히도 경험이 풍부한 (그리고 솔직히 말해서 똑똑한) 시스템 관리자 중 한 명이 저를 도와주었습니다. 그들은 내 새로운 절차를 알아차리고 조사한 다음 정중하게 나를 따로 불러 내 방식의 오류를 설명했습니다. 그런 다음 그들은 사람들이 필요로 하는 셀프 서비스 기능을 제공하면서도 재앙이 발생할 가능성을 줄이는 솔루션을 찾는 데 시간을 들였습니다. 제가 직접 편집하고 신뢰할 수 없는 기억에 따르면, 저는 제 자신과 제 구성 모두에 개선 사항이 있어서 감사했습니다.

공유, 협업 및 비난 없는 문제 해결의 그러한 행동은 수년 동안 저와 함께 해왔으며 때때로 누군가의 보안 실수를 도울 수 있었기를 바랍니다.  

이런 맥락에서 Puppet State of DevOps 보고서를 읽어보면 소프트웨어 제공 라이프사이클 초기에 보안을 통합하면 결과적으로 보안이 더 강화된다는 사실을 알 수 있습니다.

보고서를 살펴보면 보안을 소프트웨어 라이프사이클로 옮기는 것의 이점은 보안 도구를 파이프라인으로 옮기는 것만큼, 아니 그보다 더 많이 DevOps 동작 원칙을 보안 팀으로 옮기는 데 달려 있다는 것이 분명합니다.

보다 전통적인 보안 운영 관행이 테스트와 제어에 초점을 두는 반면(대부분 앱 팀은 해결해야 할 여러 문제를 보여주는 도구에서 생성된 보안 보고서를 받은 적이 있을 것입니다), DevOps 원칙을 기반으로 하는 접근 방식은 조기 협업, 공유 및 공동 책임을 장려합니다.

보고서의 "보안 태세 개선" 섹션(31페이지부터 시작)을 살펴보면, 적절한 제어 및 기술을 도입하는 것보다 소프트웨어 및 인프라의 설계 및 구축에 보안 사고를 마찰 없이 주입하는 것이 얼마나 중요한지 이해하는 것이 중요합니다.

보안 전문가의 기술과 사고방식을 소프트웨어 제공 파이프라인의 핵심에 공유하고 통합하는 데 이점이 있다면 가장 중요한 변화 중 일부는 행동적 변화가 될 것입니다.

소프트웨어 개발 라이프사이클 초기에 보안팀을 투입하려면 확실히 적응이 필요하지만, 이러한 변화는 양방향으로 이루어져야 합니다. 보안 전문가는 새로운 작업 방식을 채택하고 현재보다 더 '개발자'적인 표현을 배워야 할 것이며, 개발 팀은 안돈 코드 의 도를 받아들여야 할 것입니다.

토요타가 개척한 품질 관리 제조 공정에서 안돈 코드와 그 위치를 조사하지 않았다면, 시간을 들여 살펴볼 가치가 충분합니다. 이 주제를 다루는 기사, 학술 논문, 서적, 심지어 고등교육 과정도 있습니다. 하지만 기술 분야의 경력을 포기하고 항상 자신에게 약속했던 MBA 학위를 취득하기 전에 이 글을 끝까지 읽어보세요. 안돈 코드에 대한 가장 중요한 사실은 가장 간단하면서도 가장 달성하기 어려운 것이라고 생각하기 때문입니다.

생산 라인에서 한 근로자가 결함으로 인해 생산을 중단하기 위해 안돈 코드를 뽑으면, 동료 근로자와 경영팀이 가장 먼저 하는 일은 달려가서 고맙다고 말하는 것입니다. 그리고 그들은 그것을 진심으로 말해야 합니다. 안돈 코드를 뽑는 것은 품질 개선을 향한 한 걸음이므로 좋은 일로 여겨진다. 관리자와 동료들은 문제로 인해 생산 라인이 중단된 것에 감사해합니다 . 왜냐하면 그것은 개선의 기회이기 때문입니다.

귀사의 개발팀은 보안팀이 결함을 찾아내고 (가상의) 케이블을 뽑아내는 것을 감사하는 마음으로 받아들일 수 있을까요? DevOps 팀은 보안 테스트에 통과한 빌드나 배포만큼 실패한 빌드나 배포도 가치 있게 여기는 법을 배울 수 있을까요?

기대하는 사업주들은, 훌륭한 소프트웨어를 만들기 위해서는 배포에서 문제가 드러나기 전에 문제를 식별하는 더 나은 테스트를 구축하면서 더 빈번한 테스트 실패를 살펴야 한다는 것을 배울 수 있을까요?

정신적으로 적응하기란 힘들 수 있죠.

당신이 이 글을 읽을 때쯤이면 불가피하게 편집상의 수정이 가해질 것이란 점에 감사하지만, 다른 사람이 내가 쓴 글을 분석하는 것을 보는 것은 항상 쉬운 일은 아닙니다. 당신의 이성적인 뇌는 더 나은 제품을 제공한다는 것을 알고 있지만, 당신 안의 침팬지는 그저 팔을 휘두르고 싶어할 뿐입니다.

따라서 채택하기 어려운 사고방식일 수 있지만 소프트웨어 수명 주기 초기에 보안을 통합하는 데 성공하는 데 중요하며 기존의 사후 검토 및 서둘러 수정하는 것보다 훨씬 낫습니다.

태도를 바꾸는 것은 전혀 다른 연구 분야이지만, 특히 업무 방식에 혁명이 일어나는 오늘날에는 IT 분야의 리더와 실무자가 능숙해져야 합니다. 새로운 기술을 도입하는 것보다 (훨씬) 더 어려운 경우가 많습니다. 보안에 있어 성공적으로 '좌회전'을 하려면(이 보고서의 데이터에 따르면 그래야 함) 기술적인 요소만큼 인간적인 요소에도 많은 시간을 할애해야 합니다.