Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

데브섹옵스

시스코가 소프트웨어 개발 과정에서 API 보안성을 확보한 방법

시간 낭비를 줄일 줄 아는 소프트웨어 개발자는 재사용할 수 있는 마이크로서비스와 그에 부합하는 API를 애플리케이션 구성요소의 기본 재료로 활용한다. 시스코의 개발자 관계/전략/경험 담당 VP 그레이스 프란시스코는 “개발자들은 이미 훌륭한 솔루션이 나와 있는 것을 재구축하는 것보다 직접 제공할 수 있는 부가 가치에 집중하고 싶어 한다. 이런 작업을 쉽게 만드는 API는 그만큼 개발자들이 소비하기 쉽다”라고 말했다.   말 그대로 개발자들은 API를 소비하고 있다. 2020년 슬래시데이터(SlashData) 설문 조사에 따르면, 거의 90%의 개발자들이 API를 어느 정도 사용하는 것으로 나타났다.  혼돈의 API 환경 API를 활용한 소프트웨어 개발 방식은 효율성이 높지만, CISO의 밤잠을 설치게 하는 보안 취약점으로 이어지기도 한다. 상호 의존적인 SaaS, 마이크로서비스, 내외부 API가 도입되면서 기업 입장에서는 이용되는 API를 파악하고 통제하는 것에 더욱 어려움을 겪고 있다. 서로 어지럽게 연결된 클라우드 네이티브 아키텍처는 “이 난장판은 너무 크고 너무 깊고 너무 높다”라고 한 닥터 수스의 말을 연상케 한다. 이런 난장판은 확장되기도 한다. API는 온프레미스 또는 클라우드에 있는 다수의 플랫폼에 걸쳐 자주 분산된다. 클라우드 네이티브 아키텍처는 강력한 보안 경계가 있는 하나의 깔끔한 단위로 몰아넣을 수 없다. 더 심한 문제는 API 자체의 보안 수준이 일정하지 않다는 점이다. 내부 및 외부 API 모두 취약하며, 코드가 취약한 API에 간접적인 의존성을 가지는 경우도 있다. API 취약성이 발생할 수 있는 계층은 클라우드 보안 태세부터 애플리케이션이 구축된 이미지, 클라우드 네이티브 애플리케이션의 구성, 애플리케이션 자체를 구성하는 소프트웨어, 클라우드 네이티브 애플리케이션의 내외부 통신을 가능하게 하는 API 구현에 이르기까지 다양하다. CI/CD 파이프라인을 중심으로 한 오늘날의 애자일 개발 문화에서는 ...

시스코 API 데브섹옵스 2022.11.16

블로그 | 새로운 전쟁터가 된 클라우드 보안

무서운 일이다. 베나피(Venafi)의 조사에 따르면, 지난 12개월 동안 클라우드 플랫폼 상에서 보안 사고를 경험한 기업이 80%를 넘는 것으로 나타났다. 더욱 우려되는 것은 이들 기업의 절반 가까이는 같은 기간에 최소 4번의 보안 사고를 보고했다는 점이다.   또한 보안 사고가 승인되지 않은 접근과 잘못된 환경 구성으로 일어났다는 것도 알 수 있다. 모두가 알고있듯이 대부분 보안 문제의 원인은 사람일 가능성이 크고, 이는 클라우드 보안도 마찬가지이다. 의미 있는 트렌드도 알 수 있는데, 많은 기업의 IT 보안이 온프레미스 시스템에서 클라우드 기반 플랫폼으로 옮겨갔다. 지난 몇 년 동안 전통적인 시스템에서 퍼블릭 클라우드로 수많은 컴퓨팅과 데이터 스토리지가 이전했다는 점을 생각하면, 예상할 수 있는 일이다. 퍼블릭 클라우드 서비스 업체는 더 나은 보안 기술을 제공한다. 이를 제대로 활용한다면, 클라우드 플랫폼이 제공하는 보안은 온프레미스 보안보다 더 효과적이어야 한다. 하지만 다른 기술과 마찬가지로 효과적으로 사용하는 방법을 모르는 사람 손에 쥐어진다면, 승인 실수나 잘못된 구성으로 역풍을 만들어 낸다. 사람 문제는 바로잡기 어렵다. 더구나 좋은 클라우드 보안 전문가의 수요가 공급을 크게 앞지르고 있다. 기업은 디지털 트랜스포메이션에 필요한 기술 인력없이 계속 진행하거나 클라우드 보안 전문가를 확보하거나 내부에서 키울 수 있을 때까지 클라우드 마이그레이션을 중단 또는 늦추는 것을 선택해야 한다. 클라우드 보안과 일반 보안을 수행하는 방식도 변화하고 있다. 보고서에서 지적했듯이, 클라우드 보안을 주도하는 책임자가 바뀌어 25%만이 클라우드 보안을 기존 보안팀의 책임에 맡긴다. 23%는 클라우드 인프라 운영팀이 클라우드 보안을 맡고, 그 외에는 협업팀이나 데브섹옵스팀이 맡는 것으로 보인다.  많은 기업이 중앙집중형 환경에서 탈중앙화 환경으로 변하고 있다. 이 때문에 총괄 주체보다는 서로 다른 여러 팀이 클라우드 보안을 한 조각씩 맡...

클라우드보안 온프레미스 데브섹옵스 2022.10.12

개발자 50% "공급망 보안 관행이 잘 확립돼 있다"

구글 클라우드(Google Cloud)의 ‘도라(Dora; DevOps Research and Assessment)’ 팀에 따르면 건강한 개발자 팀 문화와 데브섹옵스 관행 준수가 오늘날의 보안 환경에서 공급망 공격 대응에 중요하다.  기업 보안 전문가라면 구글 클라우드의 도라 팀이 이번 주 발표한 보고서(2022 Accelerate State of DevOps)에 반가울 만한 소식이 있다. 데브섹옵스 모범 사례가 점점 더 일반화되고 있다는 것.  최근 공급망 공격이 증가하면서(예: 대표적으로 지난 2021년 수많은 대기업에 피해를 끼친 솔라윈즈 공격) 이 주제가 부각되고 있다. 보고서는 주요 프레임워크에서 권장하는 많은 공급망 보안 관행이 소프트웨어 개발자 사이에서 이미 시행되고 있다고 밝혔다. 이는 지난 8년 동안 ‘계속해서 진행 중’인 설문조사 결과를 기반으로 한다(3만 3,000명 이상의 개발자).  소프트웨어 공급망 개발 문제를 해결하기 위한 2가지 주요 프레임워크가 있는데, 이는 최신 소프트웨어 개발의 복잡성에서 비롯됐다. 많은 프로젝트에 오픈소스 구성 요소, 라이선스가 부여된 라이브러리, 수많은 개발자 및 서드파티의 기여가 포함돼 있기 때문이다. 2가지 주요 프레임워크 중 하나는 구글이 지원하는 표준인 ‘소프트웨어 아티팩트용 공급망 레벨(Supply-chain Levels for Software Artifacts)’이며, 다른 하나는 NIST의 ‘보안 소프트웨어 개발 프레임워크(Secure Software Development Framework)’다. 둘 다 ▲ 소프트웨어 변경사항 2인 검토, ▲ 보호된 소스코드 플랫폼, ▲ 종속성 추적을 포함해 소프트웨어 개발을 위한 여러 모범 사례를 열거한다.  공급망 보안 회사 체인가드(Chainguard)의 보안 데이터 과학자이자 보고서 작성자 중 한 명인 존 스피드 마이어스는 “설문조사 결과, 흥미로운 점은 이러한 관행 중 상당수가 실제로 비교적 확립돼 있...

개발자 구글 클라우드 도라 2022.10.05

블로그 | 보안에 만병통치약은 없다

전 세계가 불황에 빠질지라도 예산 삭감이라는 도끼에서 생존할 분야 중 하나가 보안이다. 그러나 안전한 미래를 구현하기가 점점 더 어려워지고 있다는 사실 또한 분명하다.  SLSA(Supply-chain Levels for Software Artifacts), 텍톤(Tekton)을 비롯한 각종 솔루션이 오픈소스 서플라이 체인의 안전성을 높여줄 수 있기는 하다. 하지만 현실 속 해법은 여전히 구태의연하다. 모달 랩스의 설립자 에릭 베른하드슨은 “여전히 개발자가 더 잘 해내기를 바라고 ‘경계를 유지’하는데 의존하고 있다”라고 말했다. 그리고 이러한 비전략적 접근법은 계속해서 실패하고 있다. 베른하드슨은 “2022년의 보안은 왜 그렇게 어려운가?”라고 반문했다. 이 질문에 대한 한 가지 답은 시스템이 점점 더 복잡해지고 있으며, 이로 인해 해커가 악용할 수 있는 구멍을 남겨놓는 현실이다. 그렇다면 상황이 나아질 가능성이 있을까?     만병통치약 없음 보안이 어려운 근본적인 이유 중 하나는 시스템을 보호하기 위해서는 시스템 전체를 이해해야 한다는 진실이 자리하고 있다. 오픈소스 전문가인 사이먼 윌슨은 “보안 소프트웨어를 작성하려면 모든 것이 어떻게 작동하는지에 대한 깊은 지식이 필요하다”라고 말했다. 그에 따르면 개발자가 기본적인 이해 없이 그저 ‘모범수칙’만 따를 수 있겠지만, 이는 “우연한 실수와 새로운 보안 허점의 출현으로 이어진다”라고 말했다.  그는 개발 단계에 보안 기본값을 적용하는 자동화를 이용해 인적 오류를 줄이려는 시도에 대해 부정적인 입장을 밝혔다. 윌슨은 “도구가 우리를 구할 수 있다고 생각하지 않는다. 기본 도구가 우수하더라도 한계가 있다. 기본 도구가 어떻게 보안을 유지하는지 엔지니어가 이해하지 못하면 자신이 하는 일이 왜 나쁜지에 대한 이해 없이 보안을 파괴할 것”이라고 단언했다. 이어 “궁극적으로 보안은 사람에 달렸다. 소프트웨어를 고칠 수는 있지만 소프트웨어 뒤에 있는 사람을 고칠 때까지...

보안 데브섹옵스 속성 2022.08.24

애플리케이션 성능을 높이기 위한 데브옵스 베스트 프랙티스 7가지

데브옵스(DevOps)는 생산 중인 애플리케이션 배포와 신뢰성을 개선하기 위한 개발자와 운영팀 사이의 협업과 관련된 개발 문화다. 데브옵스 베스트 프랙티스의 보편적인 목적은 더욱 탄탄한 자동화를 통해 개발팀과 운영팀의 경계에서 관리되는, 오류에 취약한 수동 프로세스를 대체하는 것이다. 여기에는 CI/CD(Continuous Integration and Continuous Delivery)를 통한 배포 파이프라인 자동화, 컨테이너를 통한 구성 표준화, 코드형 인프라 구성 등이 포함된다. 운영 측면에서 애플리케이션의 신뢰성을 높이는 데브옵스 베스트 프랙티스는 앱 관측가능성(observability) 개선, 모니터링 증가, 클라우드 및 인프라 운영 자동화가 포함된다. 하지만 데브옵스 베스트 프랙티스가 애플리케이션, 데이터베이스, 데이터 파이프라인, 클라우드 인프라의 성능까지 개선할 수 있을까? 성능과 사용자 경험에 영향을 미칠 수 있는 7가지 데브옵스 프랙티스와 방법론을 살펴보자.   1. 시프트 레프트 보안 취약점은 새로운 기능과 함께 배포되곤 한다. 보안 문제로 인한 고장 또는 성능 저하는 사용자 경험에 영향을 미치며 상당한 비즈니스 문제를 야기한다. 데브옵스 베스트 프랙티스의 목적은 요구 사항에 대해 정보보안팀과 협업하고 CI/CD 파이프라인 안에서 코드 취약점을 테스트하며, 소프트웨어 개발 과정에서 다른 보안 활동을 구현해 보안을 강화하는 것이다. 아카마이 수석 개발 지원자 마이크 엘리슨은 “앱 신뢰성의 중요한 구성요소는 가용성과 웹 애플리케이션 공격, DDoS 공격에서 앱을 적절히 보호하기 위해 적절한 조치를 취하는 것이다. 이런 차이가 온라인과 오프라인 상태의 차이를 만든다”라고 말했다. 시프트 레프트(shift left)는 데브옵스에서 데브섹옵스(DevSecOps)로 전환하는 작업의 일환이다. 엘리슨은 “데브옵스에 보안을 추가하는 것의 이점이 점차 확연해지면서 궁극적으로 더욱 강력한 데브섹옵스 문화가 형성되고 있다. 개발자가 앱 보안...

데브옵스 베스트프랙티스 데브섹옵스 2022.06.29

글로벌 칼럼ㅣ데브섹옵스가 메타버스 보안의 핵심인 이유 

기존의 개인용 컴퓨팅과 가상현실 및 증강현실 헤드셋을 통해 사회적 연결을 강화하는 데 초점을 맞춘 3D 가상 세계의 네트워크로 정의되는 ‘메타버스’는 한때 이름조차 생소했던 개념이었다. 하지만 최근 페이스북이 ‘메타’로 사명을 바꾸면서 주목받았고, 이제 사람들은 집에서 편안하게 경험할 수 있는 완전한 디지털 세계의 가능성을 꿈꾸기 시작했다.   메타버스가 일상에 자리 잡기까지는 아직 수년은 남았지만, 애플, 에픽게임즈, 인텔, 메타, 마이크로소프트, 엔비디아, 로블록스 등의 기업이 이런 가상현실에 생명을 불어넣기 위해 노력하고 있으며, 이에 따라 많은 부분이 현실화되고 있다.  대부분의 사람들이 ‘AR 헤드셋’ 또는 (아마도) 오늘날의 게임 콘솔을 구동하는 ‘초고속 칩’이 제시하는 미래를 내다보고 있을 터다. 하지만 여기서 유념할 부분이 있다. 메타버스를 설계하고 호스팅하는 데 필요한 소프트웨어뿐만 아니라 이를 활용하고자 개발될 비즈니스 사용례가 엄청날 것이라는 점이다. 의심의 여지가 없는 부분이다. 이를 염두에 두고 메타버스에서 어떻게 보안을 달성할지 생각해 볼 필요가 있다.  메타버스는 물론, 기업의 핵심 구성요소를 ‘보호’하는 문제는 때마다 불거지는 문제다. 가장 최근에는 전 세계 모든 엔터프라이즈 시스템의 절반가량을 손상시킨 ‘아파치 로그4j 취약점’, 그리고 이보다 앞서 수만 명의 고객을 대상으로 배포된 일상적인 소프트웨어 업데이트에 악성코드를 주입했던 ‘솔라윈즈 공격’이 있었다. 악성코드는 고객의 IT 시스템에 백도어를 생성했고, 해커는 이 백도어를 사용하여 미국 기업과 정부 기관을 염탐하는 데 도움이 되는 수많은 맬웨어를 설치했다.  다시 한번, 시프트 레프트(shift left) 데브옵스 관점에서의 메타버스 보안은 (오늘날 널리 광고되고 있긴 하지만 널리 사용되진 않는) ‘자동 스캔’ 등의 기술을 사용하여 보안을 기본 프로세스로 통합하는 데 달려 있다.  소프트웨어 개발과 관련해 보안을 ‘일...

데브섹옵스 메타버스 메타버스 보안 2022.05.23

데브섹옵스 클라우드 네이티브 환경에서 ‘비밀’을 유지하는 방법

데브섹옵스(DevSecOps) 도입이 활발히 이뤄지면서 많은 기업이 클라우드 네이티브 아키텍처를 활용해 안전한 소프트웨어 결과물을 확보하는 동시에 개발, 보안, 운영 부서 간의 사일로를 허물 방안을 모색하고 있다. 하지만 데브섹옵스 여정 전반에서 해결해야 문제가 여전히 존재한다. 바로 비밀 관리다.   비밀은 기업이 비공개로 유지하고자 하는 정보로 구성된다. 로그인 인증 정보, 액세스 키, 인증서가 대표적이다. IBM의 데이터 침해 보고서에서 드러난 바와 같이 인증 정보와 비밀은 각종 사이버 공격과 데이터 침해의 단골 표적으로, 유출 시 악의적 행위자에게 초기 또는 횡적 액세스 권한을 제공하는 역할을 한다. 코드코브(Codecov), 트위치(Twitch)를 포함한 여러 데이터 침해 사건에서 허술한 보안 관리 관행이 주요한 원인으로 작용했다. 최근 삼성의 소스 코드 일부분이 노출된 삼성 데이터 침해 사건에서는 6,000개 이상의 비밀 키가 노출 정보에 포함됐다. 비밀 관리 문제의 심각성은 지난 몇 년 동안 계속해서 증가했다. 최근 깃가디언(GitGuardian)이 발행한 2022년 비밀 노출 현황 보고서(State of Secrets Sprawl 2022)에 따르면, 2021년 공개 깃허브 리포지토리를 스캔한 결과 600만 개 이상의 비밀이 감지됐다. 2020년에 비해 2배 증가한 수치다. 기업의 비밀 관리가 성숙하지 못하다는 점 자체도 문제이지만, 데브섹옵스를 지향하는 클라우드 네이티브 환경이 특히 이런 부분에 취약하다. 구체적으로 비밀 보관, 중앙 집중식 접근 방법, 액세스 제어, 비밀 사고 발생 시 대응 준비 등이 취약하다. 오픈소스 솔루션 및 관련 리포지토리의 인기가 높아지는 점도 비밀 노출을 악화시키는 요소다. 소스 코드와 이미지, 코드형 인프라(Infrastructure-as-Code, IaC) 매니페스트도 우발적으로 또는 부주의하게 비밀이 커밋되어 노출될 수 있는 영역이다. 기업은 오픈소스 기술 컨테이너 이미지와 IaC ...

데브섹옵스 클라우드네이티브 데이터침해 2022.04.06

미국 웨스턴 거버너스 대학교의 ‘원점 회귀 보안’ 성공사례

웨스턴 거버너스 대학교(Western Governors University, WGU)의 보안 담당 VP 제임스 챈들러는 ‘원점 회귀 보안(Shifting security left)’에 성공했다. 챈들러는 일종의 비즈니스 프로세스를 통해 데브옵스팀이 일정한 기준을 충족해야 하는 채점표 시스템을 구축했다. 예컨대 각 팀은 최고 점수를 획득해야 각자의 코드를 승인 없이 배포할 수 있고, 점수가 낮으면 이유를 해명해야 한다.   챈들러는 “보안이 개발 생애주기 시작부터 계속 흘러갈 수 있도록 보안을 원점으로 회귀시키는 것이 중요하다. 보안은 보안팀이 문제를 발견한 후 개발자에게 해결을 부탁할 때보다 개발자가 일상 업무 중에 관여할 때 성과가 훨씬 좋다. 이런 이유로 WGU는 보안 원점 회귀를 중점적으로 추진했다”라고 설명했다.  보안 개선을 위해 채점표를 만들게 된 것은 기술 인프라의 성능에 대한 우려 때문이었다. 미국 유타주 솔트레이크시티에 위치한 WGU는 소외계층을 대상으로 한 고등교육 제공에 주력하는 100% 온라인으로 수업을 진행하는 대학교이며, 재학생 13만 명 가운데 대부분이 미국에 거주한다. 이런 특성상 챈들러는 교내 기술 책임자와 함께 3대 보안 요소인 데이터의 기밀성, 무결성, 가용성은 물론 시스템의 신뢰성을 개선할 방법을 꾸준히 모색했다. 하지만 챈들러와 동료들은 지난 2019년 초 실시한 성능 데이터 평가에서 WGU 시스템의 신뢰성이 수준 이하라는 결론을 내렸다. 교내 플랫폼에서 정전이 발생해 학생과 교직원이 모두 피해를 입었던 상황이 발생한 것이다. 챈들러는 “이런 사태에 먼저 주목해야 한다. 학생에게 피해를 끼치면 그 즉시 심각도 1의 문제로 격상된다”라고 말했다.  1단계 : 각 팀의 기대치 일치 WGU의 IT 및 보안 책임자는 학교 도메인 내 기존 비즈니스 프로세스로는 소프트웨어를 3대 보안요소에 따라 성공적으로 배치하는 것이 어렵다고 판단했다. 이런 상황이 된 것에는 여러 이유가 있었다.  먼...

shift-left 원점회귀보안 원점회귀 2022.02.23

데브섹옵스팀에 카오스 엔지니어링이 꼭 필요한 이유

‘카오스(chaos)’와 ‘엔지니어링’이라는 단어는 보통 잘 어울리지 않는다. 훌륭한 엔지니어는 결과적으로 혼란(chaos)스러운 상황을 멀리하기 때문이다. 그러나 최근에는 여러 소프트웨어 개발자가 숨겨진 결함을 드러냄으로써 컴퓨터 시스템을 강화하기 위해 적당한 수준의 ‘카오스’를 사용한다. 카오스 특성상 결과가 보장되지는 않으므로 완벽한 방법은 아니지만, 의외로 효과적인 경우가 많다.   카오스 엔지니어링은 문서화되지 않고 예측할 수 없는 백도어를 찾아야 하는 보안 애널리스트에게 특히 유용하다. 카오스 테스트로 모든 보안 문제를 찾을 수는 없지만, 개발자가 생각하지 못한 패치하지 않은 위험한 취약점을 발견할 수 있다. 좋은 카오스 엔지니어링은 데브섹옵스팀과 데브옵스팀에 모두 도움이 된다. 안정성 또는 탄력성 문제가 곧 보안 문제로 이어지는 경우도 있고, 동일한 코딩 실수가 전체 시스템 중단이나 사이버 공격자의 침입으로 이어질 수 있어서다. 카오스 엔지니어링이란? ‘카오스 엔지니어링’은 성공적인 결과가 입증된 여러 기법을 통칭하는 신조어다. 컴퓨터 시스템을 비틀어 균형을 무너뜨리고 멈추게 만들기도 하므로 ‘퍼징(fuzzing)’이나 ‘글리칭(glitching)’이라는 용어를 사용하기도 한다. 카오스 엔지니어링은 소프트웨어에 스트레스를 가하는 무작위 행동을 주입한 후 오작동이나 버그가 나타나는지 주의 깊게 관찰하는 방법이다. 정상적인 사용 환경에서는 발견까지 몇 년이 걸리는 문제를 카오스 엔지니어링으로 비교적 짧은 시간 안에 발견하는 경우가 많다.  EFF(Electronic Freedom Foundation) 공동 설립자 존 길모어는 “코딩은 지속적인 개선 과정이며 카오스 엔지니어링은 가능한 모든 실행 경로를 찾는 속도를 높이는 대표적인 방법이다. 오랜 기간 실행되는 코드는 해당 코드를 처음 실행하는 1,000만 명의 사용자, 코드를 처음 컴파일하는 20개의 컴파일러, 그리고 코드를 처음 실행하는 5개의 운영체제를 통해 대부분의 버그...

카오스엔지니어링 취약점발견 개발 2022.01.24

소프트웨어 신뢰성 확보는 보안 강화의 지름길

지난 몇 년 간 소프트웨어 보안과 신뢰성은 비교 및 대조 대상이었다. 소프트웨어 보안과 신뢰성의 핵심 목표는 모두 기업 및 최종 사용자를 보호하는 것이다. 하지만 데브섹옵스(DevSecOps) 및 SRE(Site Reliability Engineering) 도입이 지속되고 성숙하면서 소프트웨어 보안과 신뢰성의 공통분모는 점차 커지고 있다. 그리고 기업은 데브섹옵스와 SRE를 적절히 수행했을 때 가치를 극대화할 수 있다.   사이버보안 부문에 종사했던 사람은 CIA(Confidentiality, Integrity, Availability)에 익숙하다. 특히 가용성(Availability) 관련 지표는 데브옵스와 이후 등장한 데브섹옵스로의 변화에서 중요한 요소다. DORA(Devops Research and Assessments)와 MTTR(Meantime to Recover), CFR(Change Failure Rate)이 대표적인 지표다. 제안된 변경사항이 실패해 가용성이 낮아지고 결과적으로 회복에 오랜 시간이 투입되면, 보안과 신뢰성 모두 위태로워진다.  기업은 데브옵스를 안전하게 도입해야 한다. 데브옵스 실태 보고서에 따르면, 데브옵스 도입 담당자는 가용성을 확보하기 위해 도입 속도를 늦추지는 않는다. 점차 많은 기업이 SRE 원칙을 도입하고 있으며, 고장 나거나 작동을 멈춘 시스템에서 배울 점을 찾아 취약한 시스템의 보안과 신뢰성을 높이고자 한다.  짧은 리드 타임이 보안을 강화한다 MTTR과 CFR의 관계는 명확하지만, 보안 관점에서 영향력이 높은 또 다른 DORA 지표가 존재한다. 바로 변화 지표를 위한 리드 타임으로, 작성한 코드를 프로덕션 단계에서 성공적으로 구현하는 데 걸리는 시간과 관련된 지표다. 일반적으로 기업 또는 최종 사용자에게 가치를 신속하게 전달하는 맥락에서 논의된다.  시스템 보안 업데이트를 신속하게 배치하는 것도 일종의 가치 제공이다. 프로덕션 시스템에서 안전하지 못한 구성요소나 취약점을...

데브옵스 데브섹옵스 보안 2021.11.03

"마이크로서비스 기반의 앱을 위한 데브섹옵스 구현" NIST 새 가이드

미국 연방정부도 민간 기업과 마찬가지로 클라우드, 데브섹옵스(Devsecops), 그리고 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 기반 아키텍처로 전환하는 중이다. 미국표준기술연구원(NIST)은 업계가 모범사례를 채택할 수 있도록 표준과 가이드를 제공한다.    이를 위해 NIST는 지난 9월 서비스 메시(Service Mesh)를 사용한 마이크로서비스 기반 애플리케이션을 위한 데브섹옵스 구현을 발표했다(800-204C). 이 문서는 데브섹옵스 구현, 그리고 마이크로서비스 아키텍처에 클라우드 네이티브 애플리케이션을 호스팅하기 위한 서비스 메시를 사용한 참조 플랫폼 사용에 관한 포괄적인 가이드다. 이는 현재 초안 형식이며, 전 미공군 최고 소프트웨어 책임자인 니콜라스 챌라인과 서비스 메시 분야 선두업체인 테트레이트(Tetrate)의 협업으로 작성됐다. 이 가이드는 성공적인 데브섹옵스 구현을 위한 구성 요소라고 할 수 있는 프리미티브(primitive) 개념을 사용했다. 데브섹옵스 프리미티브는 민첩한 개발을 위한 마이크로서비스 기반 애플리케이션에 가장 적합하다. 또한 데브섹옵스가 클라우드 네이티브 애플리케이션에 필요한 비즈니스 민첩성 요구사항을 촉진한다는 개념도 지원한다. 다음은 NIST 가이드의 각 세션의 내용을 분석했다.   데브섹옵스 프리미티브 구현을 위한 참조 플랫폼 이 가이드는 컨테이너 오케스트레이션과 관리 플랫폼 맥락에서 참조 플랫폼을 다룬다. 예를 들어 분류된 또는 연결이 끊긴 엄격한 환경(물리적) 또는 AWS, 애저와 같은 클라우드 서비스 제공업체(CSP) 환경과 같은 가상화된 환경 등 물리적 또는 가상 기반 인프라 위에 구축하는 방식이다. 가이드는 컨테이너 오케스트레이션 및 리소스 관리 플랫폼 사용을 권장한다. 가장 인기 있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 대표적이다. 쿠버네티스는 컨테이너화된 애플리케이션을 호스팅하는 팟(pod)을 기반으로 물리적 ...

데브섹옵스 NIST Devsecops 2021.10.29

IDG 블로그 | 클라우드 기반 워크로드의 지속적인 보안 검사가 중요한 이유

클라우드 애플리케이션 개발자는 보안 엔지니어이기도 하다. 애플리케이션 수준의 보안이 더 이상 선택지가 아니라는 점에서 이런 변화를 모를 사람은 없을 것이다. 또한 개발자는 상당한 규모의 애플리케이션을 구축해야 하는데, 이 때문에 개발자는 운영 엔지니어이자 데이터베이스 엔지니어가 되기도 한다.   개발자 대부분이 보안 전문가가 아니라는 사실이 문제다. 이 때문에 개발자에게 좀 더 안전한 클라우드 기반 애플리케이션을 구축하고 배치할 수 있는 교육과 툴과 프로세스를 제공하는 데브섹옵스 프랙티스가 필요한 것이다. 물론, 이런 문화적인 변화를 구현하려는 상당한 시간이 걸린다.  새로 등장한 개념이 이런 문제를 해결하는 데 도움이 될 것으로 보인다. 바로 CNAP(Cloud Native Application Protection) 플랫폼으로, 워크로드와 환경 구성을 지속적으로 검사해 보안 문제를 찾아 해결한다. 검사는 애플리케이션 개발부터 테스트, 배치가 진행되는 동안 계속된다. CNAP는 두 가지 종류의 보안 플랫폼을 결합한 것이다. 첫째는 CSPM(Cloud Security Posture Management)으로, 개발팀이 드러난 환경 구성의 오류나 다른 취약점을 찾는 데 이미 이용하고 있다. 둘째는 CWPP(Cloud Workload Protection Platforms)으로, 에이전트 소프트웨어를 사용해 워크로드를 보호한다. CNAP의 보안 정책은 어떤 워크로드라도 중앙에서 적용한다. 여기에는 마이크로서비스 기반 애플리케이션이나 컨테이너 기반 애플리케이션, 레거시 애플리케이션도 포함되는데, 모두 요즘 개발 중이거나 재개발 중인 애플리케이션이다.  중앙집중화된 보안 프로세스는 에이전트 소프트웨어를 사용해 사전 정의된 보안 정책을 강화한다. 게다가 이들 에이전트는 애플리케이션과 애플리케이션 환경을 지속적으로 검사해 설정된 정책에서 제외된 보안 우려사항을 찾아낸다. 이들 정책은 보통 개발자가 정의하지 않고 기업 보안팀이 정의한다. ...

CNAP CSPM CWPP 2021.09.27

데브옵스에도 여전한 보안 사각지대…핵심은 ‘설계 단계의 보안 통합’

데브옵스(DevOps)가 전 세계 소프트웨어 개발 기업 사이에서 인기를 끌고 있다. 하지만 많은 기업이 여전히 문화적인 문제와 씨름하고 있다. 차세대 클라우드 애플리케이션 개발에 필수적인 데브섹옵스(DevSecOps) 시행 과정에서 보안 담당자의 영향력을 축소하는 것이 대표적이다.   데브옵스는 도입이 차질 없이 진행될 경우 극적인 변화를 끌어낸다. 최근 깃랩(GitLab)이 개발자 약 4,300여 명을 대상으로 조사해 발표한 2021년 데브섹옵스 설문조사에 따르면, 코로나19 팬데믹으로 인해 최신 데브옵스 기술이 크게 확산한 것으로 나타났다. 여기에는 쿠버네티스(Kubernetes), AI, 머신러닝, 클라우드 컴퓨팅 등이 포함된다. 데브옵스 관련 기술을 도입하면 소프트웨어 개발에 속도가 빨라진다. 깃랩 설문조사에서 개발자의 84%가 어느 때보다 빠르게 새로운 소프트웨어를 출시하고 있으며, 다섯 명 가운데 한 명은 신규 코드를 10배 더 빨리 릴리즈하고 있다고 답했다. 데브섹옵스 도입의 문제점 개발자가 새롭고 더 빠른 개발 프로세스를 선호하는 것은 자연스럽다. 하지만 이 ‘새로운 속도’는 데브섹옵스를 둘러싸고 역설적인 문제를 만들어 냈다. 즉, 보안의 중요성이 그 어느 때보다 커졌지만, 많은 이들이 데브섹옵스를 배포 속도를 늦추는 장애요소로 인식하는 것이다. 깃랩의 보고서는 “지난해 데브옵스가 이러한 기술 도입을 견인하며 성숙해졌지만 진정한 데브섹옵스를 달성하기에 앞서 해결해야 하는 방해물이 여전히 존재한다“고 설명했다. 보안 테스트가 특히 문제다. 응답자 가운데 42%가 개발 프로세스에서 보안 테스트가 너무 늦게 진행된다고 답했으며, 유사한 비율로 보안 취약점을 발견하고 수정하는 데 어려움을 겪고 있는 것으로 나타났다. 보안 전문가 72%는 그럼에도 불구하고 소속 기업이 보안에 “적당한” 혹은 “적극적인” 노력을 기울이고 있다고 대답했다. 지난해 설문조사 결과인 59%에서 개선된 수치다. 누가 보안을 담당해야 하느냐와 같은 문제에 대한 ...

데브옵스 데브섹옵스 보고서 2021.08.26

기업이 데브섹옵스에 실패하는 가장 흔한 이유 7가지

기업은 디지털 전환 프로젝트 지원, 더 신속한 가치 제공, 경쟁 우위 확보, 보안 개선 비용 감소 등 다양한 이유로 데브섹옵스(DevSecOps)를 도입한다. 그러나 데브섹옵스 이니셔티브에 실패할 때가 있으며, 그 이유는 피할 수 없는 것들이다. 데브섹옵스 프로젝트가 실패하는 가장 흔한 이유를 알아보자.     1. 학습 문화 조성 실패 최근 매켄지(McKinsey) 보고서를 보면, 인재와 문화는 데브섹옵스를 포함한 기술 전환에 가장 큰 문제가 되는 것으로 나타났다. 지속적인 학습과 실험의 문화를 도입한 기업이 데브섹옵스에 성공할 가능성이 큰 것도 이 때문이다. '데브옵스 핸드북'에 따르면, 데브섹옵스에 성공하고 성과가 높은 조직의 성공을 위해서는 학습 문화가 열쇠다. 이는 일일 학습, 조직 학습과 개선을 위한 시간 할애, 직원 숙련도 향상을 위한 집중 투자를 통해 용이해진다. 이는 학습 구독, 수업료 지원, 자격증 환급에 대한 투자를 통해 달성할 수 있다. 기업 내부와 외부의 전문가가 전문 지식과 교훈을 공유하는 브라운 백(Brown Bag) 세션도 효과적이다.   2. 교차 기능 교육 간과 개발팀과 보안팀 사이에는 겉으로 드러나지는 않지만 널리 알려진 긴장감이 있는 경우가 많다. 따라서 학습의 필요성에 기초한 교차 기능 교육은 이런 사일로를 무너뜨리고 긴장감을 없애는 데 효과적이다. 데브섹옵스를 위한 필수 요소로 추진해야 한다. 리눅스 재단과 하버드 혁신 과학 연구소(Harvard’s Laboratory for Innovation Science)가 수행한 2020년 FOSS 기여자 설문조사를 보면, 일반적인 FOSS(Free and Open-Source Software) 개발자는 코드 보안 개선에 전체 작업 시간의 2.3%를 할애한다. 그들은 안전한 코딩과 보안을 “영혼을 말려 죽이는” 일이라고 설명한다. 기업이 “보안을 더 개발 단계 쪽으로 이동”하려 노력함에 따라 개발자는 개시 및 생산 추진에 앞서 보안 취약성을 완화...

데브섹옵스 2021.04.22

아태지역 경영진 74% “소프트웨어 개발 전 과정에 보안은 필수 요소”…데브섹옵스 필요성 절감해

마이크로 포커스가 수요일, IDC 아시아 태평양 2020 "데브섹옵스(DevSecOps) : 디지털 혁신을 위한 프레임워크” 설문 조사의 결과를 발표했다. 이번 조사에서 아시아 태평양 지역 응답자 74%가 코로나19 확산으로 보안 소프트웨어 개발 이니셔티브 수요가 급증했다고 답했다. 코로나19로 온라인 활동이 늘어나고, 디지털 서비스와 애플리케이션에 대한 사용자 기대치도 늘어났다. 한편으로 IT 리더는 점차 고조되는 사이버 위협 환경에 대응해야 하는 과제를 안게 됐다. 데브섹옵스는 이런 시점에 등장해 많은 관심을 모았으나, 아직 대다수 아시아 태평양 기업은 문제를 해결할 준비가 되지 않았고, 응답자 중 55%는 자사의 데브섹옵스 성숙도가 보통 이하 수준이라고 평가했다. 아시아 태평양 14개 지역에서 기업 경영진 약 1,200명을 대상으로 한 이번 설문조사에서는 기업의 데브섹옵스 성숙도 외에도 연관 활동과 계획, 과제, 프로세스에 관한 질문도 다뤘다. 데브섹옵스는 기획 단계부터 배포, 전송까지의 소프트웨어 개발 공급망에 보안 기능을 추가하는 실무 활동을 의미한다. 이번 조사에서는 IT 리더가 데브섹옵스 도입에 따른 이점을 인식하고는 있으나 전면 도입에 이르기까지는 아직 많은 과제를 해결해야 하는 것으로 나타났다. 오늘날의 기업은 효율적인 소프트웨어 개발, 보안 위협, 비즈니스 민첩성을 아시아 태평양 지역에서의 데브섹옵스 이니셔티브에 대한 주요 동인으로 인식하고 있다. 그러나 지역 측면에서는, 데브옵스 및 보안 팀을 연합하여 소프트웨어 개발을 개선했다고 답한 응답자는 40%에 지나지 않았으며, 인도(53%)와 중국(51%)이 가장 높은 응답률을 보였다. 한국(29%)과 일본(30%)에서 데브섹옵스 도입은 여전히 초기 단계에 머물러 있다. 마이크로 포커스 아시아 태평양 및 일본 담당 사장인 스티븐 맥널티는 “특히 최근에는 사용자나 직원이 가상 형태로 기업과 상호작용하는 경우가 늘어나고 있다. 따라서 새로운 디지털 이니셔티브를 빠르게 도입해 고객의 온...

마이크로포커스 데브섹옵스 CI/CD 2020.12.10

통계가 말하는 애플리케이션 보안 현황

지난 몇 년간 데브옵스(DevOps) 문화가 부상하면서 소프트웨어 개발에 큰 변화가 발생했고, 기업들이 새 기능과 혁신을 지원하는 데 필요한 인프라를 자동으로 축소, 또는 확장하고, 코드를 더 빨리 배포할 수 있게 되었다. 그리고 이제 개발과 운영 파이프라인에 보안을 통합시키는 데브섹옵스(DevSecOps)가 확대되면서 애플리케이션 보안에도 변화가 발생하고 있다. 그러나 업계의 새 보고서에 수록된 데이터는 여전히 ‘갭’이 존재한다는 점을 보여준다. 보안 테스트의 주체가 바뀌고 있다 ESG가 북미의 애플리케이션 개발자 및 애플리케이션 보안 담당자 378명을 조사해 발표한 새 보고서에 따르면, 많은 기관과 기업이 자신의 애플리케이션 보안 프로그램이 견고하다고 판단하고 있음에도 불구하고 알려진 취약점이 있는 코드를 계속 배포하고 있다. 취약한 코드를 배포하는 것을 결코 바람직한 일이 아니지만, 이에 대해 알고 배포하는 것이 모르고 배포하는 것보다는 낫다. 위험 평가, 문제점을 바로잡을 계획, 일시적인 경감 대책 아래 이런 결정을 내리는 경우가 많기 때문이다. 조사 대상의 약 절반이 소속 조직이 정기적으로 이렇게 하고 있다고 대답했다. 또 간헐적으로 이렇게 한다고 대답한 비율은 1/3이었다. 그 이유로는 ‘아주 중요한 일정 준수’, ‘취약점의 위험인 낮아’, ‘릴리스 주기에서 너무 늦게 문제점을 발견’이 가장 많이 언급됐다(45%). 이번 조사 결과는 가능한 개발 프로세스 초기에 보안 테스트를 통합시키는 것이 중요한 이유를 설명한다. 또한, 취약한 코드를 배포하는 것이 반드시 보안 프로그램이 견고하지 않다는 것을 알려주는 신호는 아니라는 점을 알려준다. 여러 이유에서 이런 일이 일어날 수 있고, 한 종류의 보안 테스트로는 모든 버그를 포착하기 불가능하기 때문이다.  그러나 이 보고서는 여전히 애플리케이션 보안 프로그램을 확대하는 과정에 있는 조직들이 많다는 점도 알려준다. 구체적으로 코드 기반의 3/4 이상이 애플리케이션 보안 프로그램의 대상이라고 대...

애플리케이션보안 데브옵스 데브섹옵스 2020.08.19

데브섹옵스의 정의와 잘 하기가 어려운 이유

데브섹옵스(DevSecOps)는 보안을 현대 애플리케이션 개발 및 배포에 있어서 일반적인 RR(Rapid Release) 사이클에 통합하는 것이 목적인 소프트웨어 산업의 문화적 변화이며, 데브옵스(DevOps) 운동으로도 알려져 있다. 이 개념을 도입하기 위해서는 일반적으로 기업의 개발팀과 보안팀 사이에 존재하는 공백을 보안 프로세스의 많은 부분이 자동화하고 개발팀이 자체적으로 처리하는 수준까지 메워야 한다. 데브섹옵스는 기존의 소프트웨어 개발과 어떻게 다를까? 기존에는 주요 소프트웨어 개발업체가 수개월 또는 수년에 한 번씩 새로운 버전의 애플리케이션을 배포했다. 이를 통해 코드의 품질 확보 및 보안 테스트 등 내부 또는 외부 계약을 체결한 별도의 특수팀이 수행하는 프로세스를 거칠 충분한 시간을 확보했다. 하지만 지난 10년 동안 퍼블릭 클라우드, 컨테이너, 마이크로서비스(microservice) 모델이 등장하면서 하나의 애플리케이션이 독립적으로 실행되는 작은 부분으로 나뉘게 되었다. 이로 인해 소프트웨어가 개발되는 방식이 직접 영향을 받아 새로운 기능과 코드가 계속해서 빠른 속도로 생산에 투입되는 롤링 릴리즈(rolling releases) 및 애자일 개발(agile development) 활동으로 이어졌다. 이런 프로세스 가운데 다수가 새로운 기술과 도구를 활용해 자동화되면서 기업은 더 빠르게 혁신하고 경쟁에서 앞서게 되었다. 클라우드, 컨테이너, 마이크로서비스의 발전은 업계에서 이야기하는 데브옵스 문화의 등장으로 이어졌다. 데브옵스에서는 개발자가 별도의 인프라팀을 기다리지 않고 필요한 인프라를 제공받을 수 있다. 모든 주요 클라우드 제공업체가 현재 배포 템플릿을 사용해 인프라 구성을 코드로 처리할 수 있는 API와 구성 도구를 제공하고 있다. 데브옵스 문화는 소프트웨어 개발에 많은 혁신을 가져왔지만 보안은 코드가 생산되고 공개되는 새로운 속도를 따라잡을 수 없었다. 데브섹옵스는 이를 시정하고 보안 테스트를 CI(Continuous Integra...

데브섹옵스 데브옵스 2020.07.27

IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.