보안 및 보안 센터

HackerOne에서 지원하는 공개 버그 포상 제도를 전 세계 사이버 보안 연구원 및 침투 테스터들로 구성된 그룹이 Databricks의 보안 취약성을 테스트할 수 있도록 합니다. 이 프로그램을 성공적으로 진행하기 위해 내린 몇 가지 주요 결정 사항은 다음과 같습니다.

• 응답률 및 포상과 같은 HackerOne 프로그램 통계에 투명성을 제공하여 활발하게 활동 중인 해커 커뮤니티가 이 프로그램에 적극적으로 참여하도록 유도
• 버그 포상 제출물에 빠르게 응대 - 포상 평균 소요 시간 일주일 미만
• 유효한 모든 제출물에 대한 변이 분석을 수행하여 취약점 공격에 사용될 수 있는 대체 방법을 파악하고 모든 수정 사항 확인
• 제품의 가장 중요한 부분에 대한 관심을 집중시키는 보너스 포상 추가

Databricks는 이 제도의 성공을 위해 각 제출물로부터 새로운 정보를 얻기 위해 최선을 다하고 있습니다. Databricks의 개방적이고 협력적인 버그 포상 제도에서 작성된 200건 이상의 보고서에 대해 100명 이상의 보안 연구원이 감사를 표했습니다. Databricks의 보안을 유지할 수 있도록 도와주신 모든 분들께 감사드립니다.

고객이 Databricks에서 실행되는 워크로드를 신뢰할 수 있도록 도움을 드립니다. 직접 Databricks 제품에 대한 침투 테스트나 취약성 스캔을 진행하고 싶다면 다음 단계에 따라 얼마든지 가능합니다.

1. 클라우드 서비스 제공업체 계정에 있는 데이터 플레인 시스템에서 취약성 스캔을 실행합니다.
2. 자체 코드에 테스트를 실행합니다. 단, 이러한 테스트는 클라우드 서비스 제공업체 계정에 있는 데이터 플레인(또는 다른 시스템)으로만 범위를 한정하고, 자신의 컨트롤을 평가해야 합니다.
3. Databricks 전용 배포에 액세스하여 침투 테스트를 수행하려면 Databricks 버그 포상 제도에 참여해야 합니다. 멀티 테넌트 제어 플레인에 대한 침투 테스트를 실행하려면 이 포상 프로그램에 참여해야 합니다.

Databricks는 Ideas Portal을 활용하여 기능 요청을 추적하고, 고객과 직원에 대한 투표를 허용합니다. Databricks의 기능 설계 프로세스는 설계 단계부터 개인정보 보호와 보안을 고려합니다. 첫 평가 이후 영향이 큰 기능은 엔지니어링 분야의 보안 전문가와 함께 제품 보안 팀의 보안 설계 검토를 받고, 위협 모델링과 기타 보안 검사를 거칩니다.

애자일 개발 방법론을 적용하여 새로운 기능을 여러 번의 단기 개발로 나누어 분리합니다. Databricks는 Databricks 플랫폼 개발을 외부에 위탁하지 않고 모든 개발자는 채용 시점과 그 이후에도 1년에 한 번씩 OWASP Top 10을 포함한 보안 소프트웨어 개발 훈련을 거쳐야 합니다. 프로덕션 데이터와 환경은 개발, QA, 준비 환경과 분리됩니다. 모든 코드는 다단계 인증을 포함한 SSO(Single Sign On)와 세분화된 권한이 필요한 소스 제어 시스템에 체크인됩니다. 코드 병합 시에는 각 해당 영역의 기능적 엔지니어링 책임자에게 승인을 받아야 하고, 모든 코드는 동료에게 검토를 받습니다. 제품 보안 팀은 비즈니스 논리 오류를 제거하기 위해 보안에 민감한 코드를 수동으로 검토합니다.

Databricks에서는 업계 최고의 도구를 사용하여 취약한 패키지나 코드를 찾아냅니다. 사전 프로덕션 환경에서는 자동으로 운영 체제와 설치된 패키지를 대상으로 인증된 호스트 및 컨테이너 취약성 스캔을 실행하고, 동적 및 고정 코드 분석 스캔을 병행합니다. 취약성에 대해서는 엔지니어링 티켓이 자동으로 생성되고, 관련 팀에 할당됩니다. 제품 보안팀도 중요한 취약성을 분류하여 Databricks 아키텍처에서 심각도를 평가합니다.

코드 병합 시점, 코드 병합 이후, 릴리스 시점, 프로덕션 등 SDLC 프로세스의 여러 단계에서 품질 검사(예: 유닛 테스트, 전체적 테스트)를 실행합니다. Databricks에서 진행하는 테스트에는 양성 테스트, 회귀 테스트, 음성 테스트 등이 있습니다. 배포 후에는 광범위한 모니터링을 통해 장애를 찾아냅니다. 사용자는 상태 페이지를 통해 시스템 가용성에 대한 알림을 받습니다. P0 또는 P1 문제 발생 시, Databricks 자동화가 "5가지 이유" 근본 원인 분석 방법을 트리거하여 검토를 감독할 사후 검토 팀원을 선택합니다. 검토 결과는 경영진에 전달되고 후속 정보를 추적합니다.

Databricks에는 코드를 릴리스하기 전의 공식 판정을 포함한 공식 릴리스 관리 프로세스가 있습니다. 변경 사항은 회귀를 피하도록 설계된 테스트를 거치고, 새로운 기능이 실제 워크로드에서 테스트되었는지 검증합니다. 또한 모니터링과 함께 단계별 롤아웃을 거쳐 조기에 문제를 발견합니다. 의무를 분리하기 위해 Databricks 배포 관리 시스템만 프로덕션 변경 사항을 릴리스할 수 있도록 하였고, 배포할 때마다 여러 사람의 승인이 필요합니다.

Databricks는 불변 인프라 모델을 따릅니다. 이 모델은 시스템을 패치하지 않고 교체함으로써 구성에서 일관성이 어긋날 위험을 피하고 안정성과 보안을 개선합니다. 새로운 시스템 이미지나 애플리케이션 코드가 출시되면 워크로드를 새로운 코드로 출시된 새 인스턴스로 이동합니다. 이는 제어 플레인과 데이터 플레인에 모두 적용됩니다(Databricks 아키텍처에 대한 자세한 정보는 보안 기능 섹션 참조). 코드가 프로덕션에 배포되면 인증 프로세스에서 승인 없이 추가, 제거 또는 변경되지 않은 아티팩트를 확인합니다.

SDLC 프로세스의 마지막 단계는 고객에게 제공하는 문서를 작성하는 것입니다. Databricks 문서는 소스 코드와 유사하게 관리되고, 문서는 동일한 소스 제어 시스템에 저장됩니다. 중요한 변경 사항은 기술적 리뷰는 물론이고, 문서 팀의 리뷰를 거쳐야 문서에 병합하고 공개할 수 있습니다.
문서 보기 →