GOST R 57580 및 컨테이너 가상화를 활용하는 방법 중앙은행의 대응(및 이에 대한 우리의 생각)

얼마 전 우리는 GOST R 57580(이하 간단히 GOST라고 함)의 요구 사항 준수 여부에 대한 또 다른 평가를 수행했습니다. 고객사는 전자결제 시스템을 개발하는 회사입니다. 시스템은 심각합니다. 3만 명 이상의 사용자가 있고 매일 200만 건이 넘는 거래가 발생합니다. 그들은 정보 보안을 매우 중요하게 생각합니다.

평가 과정에서 클라이언트는 개발 부서에서 가상 머신 외에 컨테이너를 사용할 계획이라고 우연히 발표했습니다. 그러나 이에 대해 클라이언트는 한 가지 문제가 있다고 덧붙였습니다. GOST에는 동일한 Docker에 대한 단어가 없습니다. 어떻게 해야 하나요? 컨테이너의 보안을 어떻게 평가하나요?

사실 GOST는 하드웨어 가상화, 즉 가상 머신, 하이퍼바이저 및 서버를 보호하는 방법에 대해서만 작성합니다. 우리는 중앙은행에 설명을 요청했습니다. 그 대답은 우리를 당황하게 했습니다.

GOST 및 가상화

우선, GOST R 57580은 "금융 기관의 정보 보안 보장을 위한 요구 사항"(FI)을 지정하는 새로운 표준이라는 점을 상기해 보겠습니다. 이러한 FI에는 지불 시스템의 운영자 및 참가자, 신용 및 비신용 조직, 운영 및 청산 센터가 포함됩니다.

1년 2021월 XNUMX일부터 FI는 다음을 수행해야 합니다. 새로운 GOST 요구 사항 준수 평가. 저희 ITGLOBAL.COM은 이러한 평가를 수행하는 감사회사입니다.

GOST에는 가상화된 환경 보호를 전담하는 하위 섹션이 있습니다(7.8번). 여기에는 "가상화"라는 용어가 지정되어 있지 않으며 하드웨어 가상화와 컨테이너 가상화로 구분되지 않습니다. 모든 IT 전문가는 기술적인 관점에서 이것이 잘못된 것이라고 말할 것입니다. 가상 머신(VM)과 컨테이너는 서로 다른 격리 원칙을 가진 서로 다른 환경입니다. VM과 Docker 컨테이너가 배포되는 호스트의 취약점이라는 관점에서 보면 이 역시 큰 차이입니다.

VM과 컨테이너의 정보 보안에 대한 평가도 달라야 한다는 것이 밝혀졌습니다.

중앙 은행에 대한 질문

우리는 이를 중앙은행 정보보안부로 보냈습니다(질문은 축약형으로 제시합니다).

1. GOST 규정 준수를 평가할 때 Docker 유형의 가상 컨테이너를 어떻게 고려합니까? GOST의 하위 섹션 7.8에 따라 기술을 평가하는 것이 맞습니까?
2. 가상 컨테이너 관리 도구를 평가하는 방법은 무엇입니까? 이를 서버 가상화 구성 요소와 동일시하고 GOST의 동일한 하위 섹션에 따라 평가할 수 있습니까?
3. Docker 컨테이너 내부 정보의 보안을 별도로 평가해야 합니까? 그렇다면 평가 과정에서 이에 대해 어떤 안전 장치를 고려해야 합니까?
4. 컨테이너화가 가상 인프라와 동일하고 하위 섹션 7.8에 따라 평가되는 경우 특수 정보 보안 도구 구현에 대한 GOST 요구 사항은 어떻게 구현됩니까?

중앙은행의 대응

아래는 주요 발췌문입니다.

“GOST R 57580.1-2017은 GOST R 7.8-57580.1의 다음 조치 ZI 하위 섹션 2017과 관련하여 기술적 조치를 적용하여 구현 요구 사항을 설정합니다. 부서의 의견에 따르면 이 조치는 컨테이너 가상화를 사용하는 경우까지 확장될 수 있습니다. 기술은 다음을 고려합니다.

• 가상 머신 및 가상화 서버 구성 요소에 대한 논리적 액세스를 구현할 때 식별, 인증, 권한 부여(액세스 제어)를 구성하기 위한 조치 ZSV.1 - ZSV.11의 구현은 컨테이너 가상화 기술을 사용하는 경우와 다를 수 있습니다. 이를 고려하여 여러 조치(예: ZVS.6 및 ZVS.7)를 구현하기 위해 금융 기관이 동일한 목표를 추구하는 보상 조치를 개발하도록 권장하는 것이 가능하다고 믿습니다.
• 가상 머신의 정보 상호 작용 조직 및 제어를 위한 조치 ZSV.13 - ZSV.22의 구현은 가상화 기술을 구현하고 다양한 보안 회로에 속하는 정보화 개체를 구별하기 위해 금융 조직의 컴퓨터 네트워크 분할을 제공합니다. 이를 고려하여 컨테이너 가상화 기술을 사용할 때(실행 가능한 가상 컨테이너 및 운영 체제 수준에서 사용되는 가상화 시스템과 관련하여) 적절한 분할을 제공하는 것이 바람직하다고 생각합니다.
• 가상 머신의 이미지 보호를 구성하기 위한 조치 ZSV.26, ZSV.29 - ZSV.31의 구현은 가상 컨테이너의 기본 및 현재 이미지를 보호하기 위해서도 유사하게 수행되어야 합니다.
• 가상 머신 및 서버 가상화 구성 요소에 대한 액세스와 관련된 정보 보안 이벤트를 기록하기 위한 조치 ZVS.32 - ZVS.43의 구현은 컨테이너 가상화 기술을 구현하는 가상화 환경 요소와 관련하여 유추하여 수행되어야 합니다.

무슨 뜻인가요

중앙은행 정보보안부의 답변에서 나온 두 가지 주요 결론은 다음과 같습니다.

• 컨테이너를 보호하기 위한 조치는 가상 머신을 보호하기 위한 조치와 다르지 않습니다.
• 따라서 정보 보안의 맥락에서 중앙 은행은 Docker 컨테이너와 VM이라는 두 가지 유형의 가상화를 동일시합니다.

답변에는 위협을 무력화하기 위해 적용해야 할 '보상 조치'도 언급됐다. 이러한 "보상 조치"가 무엇인지, 그리고 그 적절성, 완전성 및 효율성을 측정하는 방법이 불분명합니다.

중앙은행 입장에 어떤 문제가 있나요?

평가(및 자체 평가) 중에 중앙 은행의 권장 사항을 사용하는 경우 여러 가지 기술적, 논리적 어려움을 해결해야 합니다.

• 각 실행 가능 컨테이너에는 바이러스 백신, 무결성 모니터링, 로그 작업, DLP 시스템(데이터 누출 방지) 등 정보 보호 소프트웨어(IP)를 설치해야 합니다. 이 모든 것을 VM에는 문제 없이 설치할 수 있지만, 컨테이너의 경우 정보보안을 설치하는 것은 어불성설이다. 컨테이너에는 서비스가 작동하는 데 필요한 최소한의 "바디 키트"가 들어 있습니다. SZI를 설치하면 그 의미와 모순됩니다.
• 컨테이너 이미지도 같은 원칙에 따라 보호해야 하는데, 이를 구현하는 방법도 불분명하다.
• GOST에서는 서버 가상화 구성 요소, 즉 하이퍼바이저에 대한 액세스를 제한해야 합니다. Docker의 경우 서버 구성 요소로 간주되는 것은 무엇입니까? 이는 각 컨테이너가 별도의 호스트에서 실행되어야 한다는 의미가 아닌가요?
• 기존 가상화의 경우 보안 윤곽선과 네트워크 세그먼트로 VM을 구분할 수 있는 경우 동일한 호스트 내의 Docker 컨테이너의 경우에는 그렇지 않습니다.

실제로 각 감사자는 자신의 지식과 경험을 바탕으로 자신만의 방식으로 컨테이너의 보안을 평가할 가능성이 높습니다. 글쎄, 둘 중 하나도 없으면 전혀 평가하지 마십시오.

만일을 대비해 1년 2021월 0,7일부터 최소 점수가 XNUMX 이상이어야 한다는 점을 추가하겠습니다.

그건 그렇고, 우리는 GOST 57580 및 중앙 은행 규정의 요구 사항과 관련된 규제 기관의 응답과 의견을 정기적으로 게시합니다. 전보 채널.

무엇을

우리 생각에는 금융 기관이 문제를 해결하기 위한 옵션은 두 가지뿐입니다.

1. 컨테이너 구현을 피하세요

하드웨어 가상화만 사용할 준비가 되어 있으면서 동시에 GOST에 따른 낮은 등급과 중앙 은행의 벌금을 두려워하는 사람들을 위한 솔루션입니다.

플러스 : GOST 하위 섹션 7.8의 요구 사항을 준수하는 것이 더 쉽습니다.

빼기 : 우리는 컨테이너 가상화, 특히 Docker와 Kubernetes를 기반으로 하는 새로운 개발 도구를 포기해야 합니다.

2. GOST 7.8항의 요구 사항 준수를 거부합니다.

그러나 동시에 컨테이너 작업 시 정보 보안을 보장하는 모범 사례를 적용하세요. 이는 새로운 기술과 그 기술이 제공하는 기회를 소중히 여기는 사람들을 위한 솔루션입니다. "모범 사례"란 Docker 컨테이너의 보안을 보장하기 위해 업계에서 인정하는 표준 및 표준을 의미합니다.

• 호스트 OS의 보안, 적절하게 구성된 로깅, 컨테이너 간 데이터 교환 금지 등
• Docker Trust 기능을 사용하여 이미지의 무결성을 확인하고 내장된 취약점 스캐너를 사용합니다.
• 원격 액세스 보안과 네트워크 모델 전체를 잊어서는 안 됩니다. ARP 스푸핑 및 MAC 플러딩과 같은 공격은 취소되지 않았습니다.

플러스 : 컨테이너 가상화 사용에 대한 기술적 제한이 없습니다.

빼기 : GOST 요구 사항을 준수하지 않은 경우 규제 당국이 처벌할 가능성이 높습니다.

결론

우리 고객은 컨테이너를 포기하지 않기로 결정했습니다. 동시에 그는 작업 범위와 Docker로의 전환 시기(57580개월 동안 지속)를 크게 재고해야 했습니다. 고객은 위험을 매우 잘 이해하고 있습니다. 그는 또한 GOST R XNUMX 준수에 대한 다음 평가에서 많은 부분이 감사자에게 달려 있다는 것을 이해합니다.

이 상황에서 당신은 어떻게 하시겠습니까?

출처 : habr.com