Red Hat 블로그에 게시된 CC 인증 관련 글을 전문 번역했다. Red Hat 홈페이지에서는 이 글을 FAQ라는 이름으로 정리해두기도 했다(관련 링크는 읽다보면 나오니 생략). 한 벤더의 입장이지만, CC(공통평가기준)의 현실을 잘 반영한 글이라 생각해서 번역해두고 싶었다.
공통평가기준이 뭔가요?
공통평가기준(CC, Common Criteria)은 컴퓨터 정보보호 소프트웨어를 보증하는 국제 표준(ISO/IEC 15408)입니다. 컴퓨터 시스템은 보호프로파일을 통해 공통평가기준에서 도출된 요구사항들을 만족시킬 수 있는 특정 등급으로 보증을 받을 수 있습니다. 정부 사이에 체결되는 공통평가기준 상호인정 협정에 서명한 2627개 국가가 회원국에서 획득한 인증서를 상호인정하고 있습니다(1).
미국에서는 NIAP(National Information Assurance Partnership)이 공통평가기준을 관장합니다(2). 각 회원국마다 각각 CC 인증기관이 있습니다. 인증기관이 CC 평가기관을 승인하면 평가기관이 제품의 실제 평가 업무를 수행합니다. 평가기관과 벤더에서 수집된 평가 증거에 따라 인증기관에서 인증을 승인받으면 국제적인 효력을 갖습니다.
인증에 보증등급이 부여되는데, 말하자면 인증의 수준을 나타냅니다. EAL4 등급은 EAL2 등급보다 신뢰도가 높습니다. 보호프로파일이 보증하는 내용보다는 보증 수준에 유의하십시오.
CC 인증은 상당히 구체적인 소프트웨어와 하드웨어의 형상 일체를 나타냅니다. 소프트웨어 버전과 하드웨어의 모델과 버전이 일치하지 않으면 인증효력을 인정받을 수 없습니다.
공통평가기준은 어떻게 운영되나요?
각국의 CC 인증기관은 운영체제, 방화벽 등과 같이 특정한 소프트웨어에 요구되는 사항 집합을 개발합니다. 보호프로파일(Protection Profile)은 이러한 요건들을 의미합니다. Red Hat을 비롯한 벤더는 제3자 평가기관과 함께 벤더가 보호프로파일을 만족하는지 문서화 작업을 수행합니다. 평가받는 특정한 하드웨어와 소프트웨어가 모두 평가대상(TOE, Target of Evaluation)이 됩니다. 여러 달에 걸쳐 평가기관은 제출할 패키지를 준비합니다. 보통 이 상태가 “평가 진행 중”이라 알려져 있습니다(3).
패키지가 완성되면 인증기관에 제출합니다. 인증기관에서 패키지를 검토하여 승인하면 제품은 비로소 보안목표에 부합하여 “CC 인증을 획득한” 것이 됩니다.
왜 Red Hat에 공통평가기준이 필요하죠?
공통평가기준은 미국을 비롯한 각 국가의 정부에서 사용하는 소프트웨어에 요구되는 의무사항입니다. 미국 내 다른 산업분야에서도 공통평가기준을 요구하기도 합니다. 고객에게 중요한 것이기에 Red Hat은 이러한 표준을 만족하고자 시간과 에너지를 투입합니다.
어떤 Red Hat 제품이 공통평가기준 인증을 받았나요?
현재 Red Hat Enterprise Linux(RHEL) 5.x와 6.x 버전이 공통평가기준을 만족합니다(4). 그리고 JBoss Application Platform 5도 여러 버전에 걸쳐 인증을 획득했습니다. Fedora와 CentOS가 RHEL과 관련되어 있다고는 하지만 CC 인증을 획득하지 않았다는 점을 유념하십시오. 공통평가기준 포탈(영문)에서 인증 받은 제품의 버전과 평가 등급 정보를 제공합니다. Red Hat에서도 자사의 제품이 획득한 인증 및 인가 목록(영문)을 제공합니다.
RHEL 마이너 릴리즈도 인증을 받나요?
마이너 릴리즈나 버그 픽스, 또는 보안 이슈가 있을 때 대다수 고객들은 최신 위협으로부터 안전을 유지할 수 있도록 시스템을 패치하고자 합니다. 이것을 기술 관점에서 보면 컴플라이언스를 준수할 수 없음을 의미합니다. 기관의 인증 주체(CA)는 대부분의 시스템에 이러한 업데이트를 기본적인 보안 수단으로 요구합니다. 그것만으로도 이미 공통평가기준을 위배하는 것으로 볼 수 있습니다.
아무리 낙관하더라도, 두 가지 이유에서 CC 평가를 특정한 마이너 버전과 연결짓기는 어렵습니다.
첫째, 인증은 절대로 특정 마이너 버전에 정확하게 일치시킬 수 없습니다. RHEL 마이너 버전은 지속적인 업데이트의 흐름에서 편의상 사용되는 특정 위치 정보일 뿐입니다. 예를 들어 CC 타겟 버전을 RHEL 6.2로 시작했지만, 평가받은 형상은 불가피하게 6.2 버전에서 업데이트된 패키지가 되어버립니다. FIPS의 경우 인증은 RHEL 버전이 아니라 패키지 버전과 연계되어 있습니다. 그래서 어떤 RHEL 버전을 사용하든, OpenSSH 서버 패키지 5.3p1-70.el6은 인증받은 버전입니다.
첫번째는 두 번째 이유로 이어집니다. 과거에 고객들은 /etc/redhat-release와 CC 문서가 정확히 일치해야 했기 때문에 기약없이 업데이트도, 패치도 이뤄지지 않은 시스템만 사용하도록 강요받았습니다. 이같은 정책은 RHEL 6.2, 6.2, 6.4, 그 외 기타 버전에도 인증받은 패키지 버전이 포함되어 있을 수 있다는 점, 그리고 인증받은 패키지 이후에도 보안 패치가 필요하다는 점을 간과합니다. “꼭 버전 X만 사용해야 합니다”라는 말은 고객을 낙담시킵니다. 이것은 CC 인증에 의도된 운영 방식이 아닙니다. 공통평가기준은 실용적인 패치와 오류 대응 전략을 실행하는 프로그램의 시작점이나 베이스라인으로서 다루어야 합니다.
“평가 진행 중”인 제품을 사용해도 되나요?
NSTISSP #11에 따라 정부 기관은 미국이 승인한 보호프로파일에 따라 인증받은 제품을 사용해야 하고, 그렇지 않으면 다른 프로파일에 따라 인증받은 제품의 사용을 허용합니다. 그마저도 만족할 수 없다면, 평가 진행 중인 제품인지 확인해야 합니다.
Red Hat은 이미 여러 차례 성공적인 공통평가기준 평가 과정을 거쳐왔습니다. 제품은 “평가 진행 중”이라는 표현과 같이 모호하지 않습니다. 제품이 “평가 진행 중”이라면, 제품이 인증을 획득할만한 수준의 높은 신뢰도를 갖습니다. 우리는 고객들과 인증기관, 인증위임기관과 협력하여 인증 및 승인 패키지의 검토에 필요한 정보를 제공하도록 협조합니다.
인증획득 시점이 걸립니다. 당장 배치해야 한다구요!
Red Hat은 고객이 자신에게 익숙한 RHEL 버전을 사용할 수 있도록 하고 있습니다. Red Hat을 구독하시면 어떤 버전이든 사용하실 수 있습니다. 바로 오늘 구독 신청하시고 현재 인증받은 버전을 배치하십시오. 그리고 최신 버전이 인증되면 별도 비용없이 사용할 수 있습니다.
NIAP 웹사이트에서 공통평가기준 인증서를 찾을 수 없던데요?
Red Hat Enterprise Linux 6는 운영체제 보호프로파일을 수용하여 BSI로부터 EAL4+ 인증을 받았습니다. 이것은 공통평가기준 상호인정협정에 따라 NIAP에게서 인증을 받은 것과 동등합니다. 공통평가기준 상호인정협정의 자세한 내용은 CCRA 웹사이트(영문)에서 확인할 수 있습니다. 웹사이트에서 상호인정협정을 체결한 회원국 목록을 확인하십시오.
공통평가기준에 따라 구성된 시스템은 어떻게 유지보수하죠?
yum 업데이트 도구에 보안 플러그인을 사용해 보안 패치만 설치할 수 있습니다. 시스템에 보안 플러그인을 적용하면 보안 이슈와 관련된 업데이트 외에 버그 패치나 기능 확장 업데이트를 설치하지 않습니다. 이렇게 함으로써 보안 업데이트 요구사항을 만족하면서도 더 안정적인 시스템을 유지할 수 있습니다.
보안 플러그인을 설치하려면 root 권한 프롬프트에서 아래와 같이 명령을 실행하십시오.
yum install yum-plugin-security
yum updateinfo
yum update --security
Shell
복사
일단 보안 업데이트가 추가된 시스템은 공통평가기준에 의해 평가받은 형상이 변경되므로 시스템에서 인증은 유효하지 않습니다. 시스템을 유지보수에 권장하는 방식은 먼저 CC 인증받은 형상에서 시작해 DISA(Defense Information Systems Agency)의 규제에 따라 패치를 실시하는 것입니다. 평가 및 인가 과정 중인 제품은 인증기관이나 인증위임기관에 상담하시면 가이드라인과 요건을 수립하는데 도움이 될 겁니다(5).
답변이 필요한 질문은 어디에 물어봐야 하나요?
Red Hat Support에서 언제든 Red Hat 제품과 관련된 질문을 하실 수 있습니다.
더 읽을거리
•
Red Hat | Government statndards - http://www.redhat.com/en/technologies/industries/government/standards
•
공통평가기준 상호인정협정 - https://www.commoncriteriaportal.org/ccra/
1.
CCRA 회원국은 인증서 발행국과 인증서 수용국으로 나뉜다. 작성일 기준, 발행국은 17개국(네덜란드, 노르웨이, 뉴질랜드, 독일, 말레이시아, 미국, 스웨덴, 스페인, 영국, 이탈리아, 인도, 일본, 캐나다, 터키, 프랑스, 한국, 호주)이며, 인증서 수용국은 10개국(그리스, 덴마크, 싱가포르, 오스트리아, 이스라엘, 체코, 카타르, 파키스탄, 핀란드, 헝가리)이다.
3.
여기서 설명하는 내용은 미국의 평가스킴으로, 평가기관이 보안목표명세서(Security Target) 작성에 관여하고, 평가 보증에 필요한 증거를 수집해 평가 보고서를 작성한다. 우리나라의 평가스킴은 인증 평가 신청 시점에 신청자가 모든 인증용 보증문서 준비를 마친 상태여야 한다. 평가기관은 이미 작성된 보증문서들을 기초로 평가 업무를 수행한다. 이런 이유에서 CC 인증이 필요한 업체마다 각각 CC 인증 업무를 전담하는 인력이 따로 있다. 우리나라와 같은 방식의 평가 스킴은 공통평가기준 참고 문서가 권고하는 방식에서 한참 벗어나 있다.
4.
2017년 8월 기준, RHEL 7이 평가 진행 중이다. Red Hat은 단일 제품에 여러 개의 인증을 받고 있다. 하드웨어 플랫폼에 따라, 또는 특정한 기능을 중심으로, 수용하는 PP에 따라 RHEL6에서도 여러가지 인증이 존재한다. 게다가, 인증된 TOE마다 마이너 버전이 다르다.
5.
이 또한 우리나라 현실과 거리가 있다. 우리나라에서는 인증받은 버전만을 사용하도록 강제하고 있다(실제로는 여러가지 현실적인 이유로 잘 지켜지지 않는 것같다). 우리나라의 IT 시스템 보안 정책은 보안 업데이트에 대한 관용이 전혀 없다. 외국에서는 변경승인이 그리 많지 않은 것같다. 또한 우리나라에는 인증 업무를 위임받은 기관이 없다. 미국의 사례는 제도보다 제도의 운영이 중요함을 보여 준다. 엄격한, 융통성없는 국내 인증스킴 보다 낫다. 인증이 제품보다 우선하는 경우가 많고(인증기관의 인증제일주의), 버그 수정이나 취약성 패치는 사후인증이어도 될 것을 사전인증을 해야 공공기관에 배포할 수 있다는 비현실성이 있다. 인증기관의 고자세도 한몫하는 듯 싶다. 앞뒤가 다르다는 인상도 많이 준다. 면전에서는 친절해도 평가기관을 통해 이야기하면 일방향 소통일 뿐이다.
