신시웨이 | 데이터베이스 보안 전문 기업 - PR - 뉴스룸

본문바로가기

PR

신시웨이의 최신 소식과 다양한 IT/보안 정보를 제공합니다.

IT·보안
정보보안 인증 및 평가 제도(Common Criteria 인증)

정보기술의 발달로 기업이 보호해야 할 정보가 급격히 증가함에 따라 정보보호 대책의 일환으로 다양한 정보보호시스템이 도입·운영 되면서 이러한 정보보호시스템의 보안성과 신뢰성 확보를 위해 세계 각국에서 다양한 평가기준이 개발되어 왔다.기존 TCSEC, ITSEC, CTCPEC와 같이 서로 다른 나라에서 개발된 평가 기준을 통해 평가받은 정보보호 제품들을 다른 나라에 판매하기 위해서는 해당 국가가 사용하는 평가기준으로 재평가받아야만 수출할 수 있었다. 이러한 문제점을 해결하기 위해 정보보호 제품 공통평가기준(CC : Common Criteria)을 개발하여 평가 기준을 단일화하고 ISO/IEC 15408 국제표춘으로 채택되어 국제 상호인증 협정 체계를 구축하였다.정보보안 인증 제도미국 TCSEC (Trusted Computer System Evaluation Criteria)오렌지 북(Orange Book)이라 불리며 미국 NCSC(National Computer Security Center)에서 발간한 안전한 컴퓨터 시스템을 위한 평가 지침서컴퓨터 시스템의 보안을 평가하기 위해 보안 정책(Security Policy), 책임성(Accountability), 보증(Assurance), 문서(Documentation) 4가지의 기본 요구사항과 만족 수준에 따른 7단계의 평가 등급이 있다Bell-LaPadula Model 정보보안 모델 기반의 기밀성만을 다루며 가용성과 무결성은 다루지 않음 * Bell-LaPadula Medel > No Read Up : 낮은 등급의 주체는 높은 등급의 객체를 읽을 수 없음 > No Write Down : 높은 등급의 주체는 낮은 등급의 객체를 수정할 수 없음 > 한계점 : 낮은 등급의 주체가 높은 등급의 객체를 수정하는 무결성 문제 발생기능성(Functionality)과 보증(Assurance)을 분리하지 않음유럽 ITSEC (Information Technology Security Evaluation Criteria)유럽의 네덜란드, 독일, 영국, 프랑스 4개국이 미국 TCSEC를 참고하여 제정한 평가 기준TCSEC는 기밀성만을 강조한 반면 ITSEC은 기밀성, 가용성, 무결성을 모두 다루며 가능성(Functionality)과 보증(Assurance)을 분리하여 평가* 기능성 : F1 - F10* 보 증 : E0 - E6평가기준으로 조직적, 관리적 통제 및 보안 제품의 기능성 등 기술적 측면보다 비기술적 측면을 중시유럽 공통의 지침이지만 유럽 각국 나름의 평가체계 구성이 가능하며, 상세한 절차나 체계를 규정하지 않는 대신 평가방법론 및 해설을 중시캐나다 CTCPEC (Canadian Trusted Computer Product Evaluation Criteria)캐나다의 CSE(Communications Security Establishment)가 개발한 평가기준으로 기능성과 보증성에 대한 요구사항으로 구성됨기능 기준은 비밀성, 무결성, 가용성, 책임성 4가지로 구분되며 보증의 평가등급은 T0~T7의 8등급으로 구성됨보증 평가기준의 구성요소는 구조, 개발환경, 개발증거, 운영환경, 보안환경, 보안시험의 6가지 요구사항으로 구성평가 시에는 제품의 서비스 수준의 집합을 전체로서 평가하여 해당 보증등급에 부합하는지 결정하며 제품이 목표하는 서비스 수준의 요구사항에 부합하지 못하면 T0 등급으로 평가됨공통 평가기준 (CC : Common Criteria for Information Technology Security Evaluation) 인증 제도- CC인증 개요CC인증은 국가마다 상이한 평가기준을 연동시키고 평가결과를 상호 인정하기 위해 네덜란드, 독일, 미국, 영국, 캐나다, 프랑스 6개국 7개 정부기구로 구성된 공통기준 프로젝트 지원기구(Common Criteria Project Sponsoring Organizations)를 통해 제정된 평가기준이다.미국의 TCSEC, 유럽의 ITSEC, 캐나다의 CTCPEC 등을 기반으로 개발되었으며 각국의 평가기준을 단일화하여 하드웨어, 소프트웨어 등 IT제품의 공통의 요구사항들을 제시하여 독립적으로 수행된 보안성 평가 결과의 상호인정이 가능하도록 하였다.CCRA(Common Criteria Recognition Arrangement)에 의거하여 인증서 발행국인 CAP(Certificate Authorizing Participants)는 다른 국가에서 발행된 인증서를 자국에서 인정해주는 동시에 자국 내 국제 상호인증 협정에 의해 공인된 평가 및 인증기관을 통해 발행된 인증서를 타국에서 인정받을 수 있다.반면 인증서 수용국인 CCP(Certificate Consuming Participants)는 타국에서 발행된 인증서를 자국에서 인정해 주지만 자국의 평가인증제도를 통해 발행된 인증서는 타국에서 인정받지 못한다. 한국은 현재 인증서 발행국으로 등록되어 있으며 국내의 CC 인증기관을 통해 인증받은 제품은 타 인증서 발행국 및 인증서 수용국에서 동일한 인증 효력을 발휘한다.CC인증 구성CC는 제1부 소개 및 일반 모델,제2부 보안 기능 컴포넌트,제3부 보증 컴포넌트 세 부분으로 구성되어 있다.‘제1부 소개 및 일반 모델’에서는 정보보호시스템 보안성 평가의 원칙과 일반 개념을 정의한다.‘제2부 보안기능컴포넌트’는 평가대상(TOE: Target Of Evaluation)의 보안기능을 표현하기 위한 기능 컴포넌트를 클래스, 패밀리, 컴포넌트의 계층관계로 구분하고 각 기능 컴포넌트에 대한 보안기능요구사항(SFR: Security Functional Requirements)을 정의한다.‘제3부 보증컴포넌트’는 보증 등급(EAL : Evaluation Assurance Level)을 구성하는 보증요구사항(SAR: Security Assurance Requirement), 보호프로파일(PP: Protection Profile) 및 보안목표명세서(ST: Security Target) 평가를 위한 기준을 정의한다.보안기능요구사항은 정보보호제품의 기능요구사항을 적절한 기준에 따라 분류하고 표준화한 것으로 11개의 클래스로 정의되어 있다. 보호프로파일이나 보안목표명세서에서 평가대상의 보안행동을 보안기능요구사항에서 제시된 표준에 따라 설명하여 보안목적을 구체적으로 어떻게 만족하는지 명시하기 위해 사용된다.보증 요구사항은 정보보호 제품의 보증 수준을 측정하기 위해 정보보증 요구사항을 표준화한 것으로 8개의 클래스로 정의되어 있다. 보안 기능 요구사항이 체계적으로 구성되어 평가대상의 보안 목표를 만족하는지 검토하고 보증하기 위해 사용된다.보호프로파일은 특정 제품군이나 시스템에 적용할 수 있는 공통적인 보안 기능 요구사항을 정의한 것으로 표준화된 기준을 제시하기 위해 사용된다. 같은 분류에 속하는 제품이나 시스템은 보호프로파일을 새로 작성할 필요 없이 기존의 보호프로파일을 재사용할 수 있다. 현재 국내에서는 한국인터넷진흥원(KISA)과 국가보안기술연구소(NSR)에서 나누어 개발하고 있다.보안 목표 명세서는 평가대상(TOE)의 보안 요구사항 및 평가대상에 의해 제공대는 보안대책을 정의한 것으로 개발자, 평가자, 소비자 간 보안 특성에 관한 합의와 평가범위에 대한 기준이 된다. 보안 요구사항은 보호프로파일로부터 정의될 수 있고, 공통 평가기준의 보안 기능 요구사항 및 보증 요구사항 컴포넌트를 사용하여 직접 정의할 수도 있으며, 공통 평가기준에 포함되지 않은 보안 요구사항을 사용하여 정의될 수도 있다.CC인증 절차국내 정보보호 제품 인증 체계는 「국가정보화 기본법」제38조 및 시행령 제35조, 「정보보호시스템 평가·인증 지침」(미래창조과학부고시 제2013-52호)에 근거하여 다음과 같이 운영되고 있다.정책기관인 미래창조과학부는 정보보호 제품 인증에 관한 국가정책 결정, 평가인증 수행규정, 평가기준 방법론,보호프로파일 등을 수립 및 시행한다. 인증기관인 IT보안인증 사무국은 평가기관의 평가업무 감독, 인증보고서 작성 및 인증서 발급, 인증제품에 대한 사후관리 등의 역할을 수행하고 있다. 평가기관은 평가업무에 관한 규정 수립 및 시행, 평가계약 체결 및 평가 수행, 개발환경 보안점검 등의 역할을 수행하며 현재 국내에는 6개의 평가기관이 있다.CC 인증절차는 준비단계, 평가 단계,인증단계, 사후관리 단계로 진행되며 인증 진행과정은 다음과 같다.준비 단계는 신청기관이 인증 평가를 신청하여 평가계약이 이루어지기까지의 과정이다. CC인증 평가신청을 위한 준비 절차 및 요건에 대해 평가기관에 문의하여 평가신청 준비에 필요한 자문을 받는다. 신청기관은 평가 자문을 통하여 평가 제출물을 준비하고 평가기관은 이를 검토하여 신청기관에 보완사항을 전달한다. 신청기관의 제출물의 검토가 적합하게 이루어지면 평가기관과 평가계약을 체결하고 인증기관에 평가계약 내용 및 제출물을 제출한다.평가 단계는 CC 인증 평가의 핵심사항으로 평가계약 체결 이후 평가기관은 평가팀을 구성하여 제출물을 평가하고, 평가보고서를 작성한다. 신청기관은 제출물 설명회를 통해 제출물에 대한 설명 및 제품의 기능 시연을 수행하여 평가 제출물에 대한 평가팀의 이해를 돕는다. 평가팀은 이를 통해 평가 제품에 대한 평가 수행계획서를 작성하여 인증기관에 제출하고 인증기관은 이를 검토하여 평가 진행에 대해 최종 승인한다.평가팀이 제출물 및 평가대상에 대한 평가 도중 발생된 문제점을 신청기관에 보완 요청을 하면 신청기관은 이를 보완하여 평가기관에 제출한다. 만약 신청기업이 보완 요청받은 사안에 대한 보완을 하지 않거나 평가를 계속 진행하기 어렵다고 인정될 경우 평가가 중단되거나 평가계약이 해지될 수 있다. 제출물 및 평가대상에 더 이상의 문제점이 없다고 판단될 경우 평가기관은 평가보고서를 작성하여 인증기관에 제출한다.인증 단계는 평가 단계를 통해 도출된 평가보고서를 인증기관이 인증위원회 개최를 통해 검토하여 평가 수행이 CC 인증 평가체계의 요구사항에 맞게 수행되었는지 확인하고, 평가결과의 적합여부를 판정하여 평가기관에 통보한다. 인증위원회를 통해 인증 승인이 적합하게 통과하면 인증기관은 평가대상에 대한 CC인증 인정서 및 인증 결과서를 교부하고, 인증된 제품을 인증제품 목록에 등재한다.사후관리 단계는 추후 신청 기업의 인증 제품이 변경되거나 인증효력 기간이 만료될 경우 변경된 사항에 대해 보안 영향 분석서를 작성하여 인증효력 유지 신청 및 인증효력 연장 신청을 통해 인증 효력을 계속해서 유지할 수 있다.신시웨이는 국내 최초로 DB 접근제어에 대한 CC인증을 획득하여 기술력을 인정 받아 오고 있으며, 현재 데이터베이스 보안 제품(DB접근제어 페트라, DB암호화 페트라 사이퍼)은 각각 EAL4, EAL3 보안 등급의 CC인증을 취득 하였고 최근 Petra Cipher v3.2 버전은 국제 CC인증을 획득 하였습니다.출처 및 참고자료1. 정보보호시스템 공통평가기준(CC V3.1 R5) 1부2. 정보보호시스템 공통평가기준(CC V3.1 R5) 2부3. 정보보호시스템 공통평가기준(CC V3.1 R5) 3부4. 정보보호시스템 공통평가방법론(CEM V3.1 R5)5. 정보보호시스템 공통평가기준(미래창조과학부고시 제2013-51호)6. 정보보호시스템 평가·인증 지침(미래창조과학부고시 제2017-7호)7. 정보보호제품 평가·인증 수행규정(2017, 미래창조과학부, IT보안인증사무국)8. 정보보호제품 평가기준 국내외 동향 및 향후 과제(2016, 금융보안원)9. 정보보호제품 평가제출물 작성 가이드(2005, 한국정보보호진흥원)10. 국방데이터베이스 정보보호 방안에 대한 연구(2001, 한국국방연구원)11. IT보안인증사무국 홈페이지 “https://itscc.kr/main/main.do”12. CCRA 홈페이지 “https://www.commoncriteriaportal.org/ccra/”글. 프레임워크팀 | 신건 대리

20.10.07
IT·보안
REST 살펴보기

단순히 하나의 브라우저만 지원하던 예전과 달리, 멀티 플랫폼, 멀티 디바이스 사용이 당연시되는 지금의 서버 프로그램은 여러 웹브라우저뿐만 아니라 아이폰, 안드로이드 등의 어플리케이션과의 통신에도 대응해야 한다. 특정 플랫폼이나 디바이스에 의존적인 서버를 만들지 않기 위해서는 범용적인 사용성을 보장하는 서버 디자인이 필요하다.이를 위해 고안된 것이 REST 이다. REST의 기본 원칙을 성실히 지킨 서비스 디자인을 “RESTful 하다.” 라고 표현하며, 이러한 원칙을 지켜서 설계된 API를 “Rest API”라고 한다.REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 스타일이다. 이는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장해 준다.REST 구성요소1. 자원(Resource) – URIUnique한 ID를 가진 Server의 Resource에 대해 Client가 요청을 보낸다.2. 행위(Verb) - MethodClient가 Server에 요청을 보내는 방식으로 POST, GET, PUT, DELETE 등이 있다.3. 표현(Representations)Server와 Client간의 데이터 전달 형태로 json, xml, text 등이 있다. 주로 Key-Value를 활용하는 Json이 사용된다.REST를 구성하는 스타일 (제약조건)1. client - server(서버-클라이언트 구조)RestAPI에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할을 확실히 구분시킴으로써 서로간의 의존성이 줄어들게 된다.2. stateless(무상태성)각각의 요청을 별개의 것으로 인식하고 처리해야 하며,이전 요청이 다음 요청에 연관되어서는 안 된다.그래서 RestAPI는 세션정보나 쿠키 정보를 활용하여 작업을 위한 상태 정보를 저장 및 관리하지 않는다. 이러한 무상태성때문에 RestAPI는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 이러한 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함입니다.3. cacheable(캐싱가능)RestAPI는 HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 활용할 수 있다. 그러므로 RestAPI에서도 캐싱 기능을 적용할 수 있는데, HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효율적으로 처리할 수 있게 도와준다.4. layered system(계층형 구조)RestAPI의 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해준다.5. code-on-demand(optional)서버에서 코드를 client로 보내서 실행할 수 있어야 한다.(ex>javascript)6. uniform interface(일관된 인터페이스)Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다. 이것은 요청을 하는 Client가 플랫폼(Android, IOS, JSP 등) 에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 의미하고, 이러한 특징 덕분에 RestAPI는 HTTP를 사용하는 모든 플랫폼에서 요청 가능하며,느슨한 결합) 형태를 갖게 되었다.현재(현실)의 REST API 한계점HTTP만 잘 따라도 대체로 REST 제약조건(아키텍쳐 스타일)을 다 만족할 수 있지만, uniform interface 제약조건의 일부를 만족시키지는 못한다.① identification of resources : uri가 리소스로 식별되면 된다.② manipulation of resources through representations : 리소스에 대한 조작 시 http 메세지에 표현을 담아서 전송해서 달성하면 된다.③ self-descriptive messages : 메시지는 스스로를 설명해야 한다.④ hypermedia as the engine of application state(HATEOAS) : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다..위처럼 uniform interface는 4가지 제약조건으로 이루어져 있는데, 오늘날 사용되는 대부분의 RestAPI는 아래 두 가지 ③, ④는 지키지 못하고 있다. REST의 기본 원칙을 성실히 지키지 않은, ‘RESTful 하지 않은’ 오늘날 대부분의 REST API를 어떻게 해야 할지에 대해 고민해볼 필요가 있다. - REST API가 아니지만 REST API라고라고 부른다. (현재 상태) - REST API 구현을 포기하고 HTTP API라고라고 부른다. - REST API를 구현하고 REST API라고라고 부른다.사실 어떻게 부르든 큰 차이는 없을 수 있지만, REST의 지향점에 대한 이해는 가져야 하지 않을까 생각해본다. 위키 피디아(REST) 토스트 밋업(REST API 제대로 알고 사용하기) 망나니 개발자([Server] Restful API란?)글. 기술지원 2팀 | 권선보 차장

20.10.07
IT·보안
신입 보안관리자가 꼭 봐야할 암호화 상식

"암호화란 무엇인가""대칭키 및 비대칭키 빠르게 알고 가자" 암호화(Encryption)IT 관련 업무를 하고 있다면 암호화(Encryption)라는 말을 수 없이 들었거나 앞으로 수 없이 들어야할 말이다. 암호화(Encryption)는 정보를 보호하기 위한 학문인 암호학(Cryptology)의 일부분으로 암호화(Encryption)는 비밀을 보장하기 위해 특정 알고리즘으로 평문(Plaintext)를 암호문(Ciphertext)으로 변환하는 것을 말한다. 반대로 복호화(Decryption)는 암호문(Ciphertext)을 평문(Plaintext)으로 변환하는 것을 말한다. 그렇다면 암호학(Cryptology)에서 말하는 암호화는 무엇을 목표로 하고 무엇을 제공(기능) 하고 있을까?궁극적인 목표는 보안 강화 일 것이며, 암호학(Cryptology)에서는 기밀성(Confidentiality), 무결성(Integrity), 인증(Authentication), 부인방지(Non-repudiation)의 기능을 제공 한다.기밀성(Confidentiality)인가 되지 않은 자는 정보를 확인 하지 못하도록 하며, 정보가 유출 되더라도 평문으로 해독 할 수 없고, 변조 또는 위조 하지 못하도록 기밀을 유지대칭키 / 비대칭키 암호화무결성(Integrity)전자 서명인증(Authentication)전자 서명대칭키 암호화(Symmetric-key Cryptography)암호화 할 때 사용하는 키와 복호화할 때 사용하는 키가 동일한 암 · 복호화 방식을 말하며, 쉽게 말해 사전에 공유된 키에 대해서만 암호화와 복호화가 가능한 암호화 방식을 이야기한다. 대칭키 암호화는 블록과 스트림 방식으로 나뉘며 블록 암호화 방식은 혼돈(confusion)과 확산(diffusion)을 이용하여 평문을 블록 단위로 나누어 암호문을 생성한다. 혼돈은 치환(substation, S-box)을 통해 생성되고, 확산은 순열(permutation, P-box)에 의해 얻게 되는데, 순열(전치)과 치환 그리고 다른 구성 요소들을 결합하여 암호화하는 것을 합성 암호화(Product Cipher)라고 한다. 합성 암호화의 반복적인 사용을 라운드(Round) 또는 회전수라 이야기하며 이러한 라운드 수는 블록의 길이, 키의 길이와 같이 암호화 강도를 결정짓는 중요한 요소이다.확산암호문과 평문 사이의 관계를 숨기는 성질로 평문의 통계적 성질을 암호문 전반에 퍼뜨려 숨기는 것을 말한다. (전치형 암호화 / 블록 암호화에 사용)라운드합성 암호화(Product Cipher)의 반복 횟수대칭키 암호화(Symmetric-key Cryptography) 특징비대칭키에 비해 키 길이가 짧고 알고리즘이 비교적 단순 하기 때문에 암 · 복호화 속도가 빠르다.키 길이가 길수록 Key Space가 길기 때문에 brute-force attack(무차별공격)에 안전 하다암 · 복호화 키가 같기 때문에 키가 오픈 될 확률이 비대칭키에 비해 높으며, 키를 자주 변경해 주어야 한다.키 분배가 어렵고 관리할 키가 많다.기밀성을 제공하며, 전자서명이 불가능 하고 부인 방지 기능이 없다.* 무차별 공격 : 특정한 암호를 풀기 위해 가능한 모든 값을 대입 블록 암호화와 스트림 암호화의 특징스트림 암호화평문에 연속 되는Key Stream을 적용하여 1bit씩 암호화XOR 연산H/W 구현에 적합(무선 암호화에 많이 사용)암/복호화 속도가 빠르다블록 암호화에 비해 안정성이 떨어진다.비대칭키 암호화(Asymmetric key Cryptography)비대칭키 암호화는 대칭키 암호화와 달리 암호화 할 때의 키와 복호화 할 때의 키가 서로 다른 암호화 방식을 이야기 한다. 즉, 개인키로 암호화를 하면 공개키로 복호화를 해야 하고, 반대로 공개키로 암호화하면 개인키로 복호화를 해야 한다. 비대칭키 암호화는 공개키 암호화라고도 한다. 비대칭키 암호화는 대칭키 암호화의 키 관리와 키 배포 방식에 대한 단점을 보완하기 위한 암호화 방식이다.그러나 키의 길이가 길어 암호화 속도가 느리기 때문에 현실적으로 비대칭키를 이용하여 데이터를 암호화하는 것은 어려운 일이다. 그렇기 때문에 대칭키를 이용하여 데이터를 암호화 하고 비대칭키 암호화 방식을 이용하여 키를 배포하는 방식을 많이 사용 하며, 전자 서명, 인증, 부인방지의 기능으로도 사용 된다.공개키 (Public key)CA(Certification Authority) 등에 공개되어 있어 누구나 사용 가능한 키개인키 (Private key)개인이 소유하고 관리하고 있는 키로 비밀키(Secret Key)라고도 함* 대칭키가 비대칭키보다 빠른이유는 대칭키는 128 ~ 256bit 비대칭키는 1024 ~ 2048bit로 키 길이가 짧고 알고리즘이 비교적 단순하기 때문이다.

20.09.21
IT·보안
쿠버네티스 기본 개념

최근 컨테이너 가상화 기술이 발달하면서 DB보안 또한 컨테이너 기술에 맞는 환경 구축을 요구하는 고객사자 점차 증가하고 있고, 최근 고객사 환경이 AKS(Azure Kubernetes Service) 기반 Docker Container에 Weblogic이 설치된 MS Azure Cloud 환경에서 DB 접근 제어 솔루션을 gateway 방식으로 접속하여 DB에 접속하는 방식으로 구성해야 한다는 요구사항이 있었습니다.해당 요구사항의 출발점은 WAS가 여러 곳에서 DB로 접속되는 포인트를 Gateway를 통하여 하나의 IP에서 DB로 접속해야 된다는 요구사항이었고 WAS의 가용성을 최대한 보장하라는 것이었습니다. 위 요구사항을 충족하기 위해서 다음과 같은 시스템 구성을 했습니다.그림에서 보는 바와 같이 App1-App4가 Container 위에 올라간 WAS Service라고 보시면 되고 해당 WAS Service들은 AKS(Azure Kubernetes Service)에 의해 컨트롤 되는 환경입니다. 따라서 위와 같은 환경에서의 효과적인 DB 보안 구축 방법을 알아보기에 앞서 쿠버네티스 개념을 먼저 알아보도록 하겠습니다.현대 산업 사회는 과거보다 수많은 데이터를 저장하는 데이터 사회입니다. 그러므로 많은 데이터를 저장하기 위해서는 저장 공간과 다양한 프로세스들을 구동할 수 있는 자원을 필요로 합니다. 과거에는 물리적인 서버를 증설하였다면 현대 사회에는 자원을 유동적으로 혹은 효율적으로 사용해야 합니다. 즉 관리는 효율적이면서 자원에 대한 비용은 효과적이어야 합니다. 따라서 서버 자원을 효율적으로 쓰기 위해서는 가상화 기술에 대해 관심을 가질 수밖에 없는데, 쿠버네티스를 좀 더 잘 이해하려면 가상화 기술들에 대한 역사를 알 필요가 있습니다.가상화 기술의 히스토리를 크게 4분류로 나눠본다면 아래의 단계로 나눠볼 수 있습니다.1. 리눅스의 자원 격리 기술2. VM의 가상화 기술3. Container의 가상화 기술4. Container를 관리하는 오케스트레이터 기술1. 리눅스의 자원 격리 기술리눅스의 자원 격리 기술은 현재 컨테이너로 서비스를 가상화하여 배포하는 형태인 Container 기술의 시초라고 볼 수 있습니다. 하지만 최초 리눅스에서 프로세스들이 독립적인 환경에서 동작하도록 하는 자원 격리 기술은 사용자들이 사용하기 어려워 잘 활용되지 못하였습니다.2. VM의 가상화 기술최초 자원 격리 기술 이후 VM 가상화가 나오게 되고 VM 가상화에서는 단일 물리 서버에 여러 대의 가상 시스템을 실행할 수 있게 하였습니다. 따라서 물리 서버에서 자원을 활용하던 것보다 효율적으로 활용할 수 있게 되었고 하드웨어의 비용을 절감할 수 있었습니다. 하지만 VM 가상화는 OS를 띄워야만 한다는 단점이 있어 작은 서비스를 제공하기 위해서도 OS를 띄워야 하여 효율이 낮다는 단점을 가지고 있었습니다.3. Container의 가상화 기술VM의 가상화 기술이 나온 후 dotCloud(현 docker)사에서 예전 리눅스의 자원 격리기술을 컨테이너라는 개념으로 사용자들이 사용하기 쉽게 만들게 되었습니다. 즉 서비스를 가상화시켜 배포를 할 수 있도록 만든 것이었습니다. VM에 비해 강점으로 컨테이너 기술은 VM처럼 각 서비스별로 OS를 띄워야 하는 것이 아니라 OS를 공유하는 개념으로 서비스마다 OS를 띄우지 않아도 된다는 장점이 있어 자동화 시에 빠르고 자원효율이 매우 높았습니다. 그리고 컨테이너 또한 VM과 마찬가지로 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있지만, 기존 인프라와의 종속성을 끊었기 때문에 클라우드나 OS 배포본에 모두 이식할 수 있다는 장점이 있었습니다. 따라서 컨테이너를 통한 서비스의 제공이 인기를 끌게 되었습니다. 4. Container를 관리하는 오케스트레이터 기술컨테이너 기술은 서비스를 가상화시켜 배포는 해주지만 운영할 때 그것 자체를 일일이 배포하고 운영하는 역할은 해주지 않습니다. 따라서 배포된 컨테이너들이 정상적으로 동작하는지 관리해주는 기술이 필요하게 되는데 이것을 ‘오케스트레이터’ 라는 솔루션으로 부르게 됩니다. 쿠버네티스는 이 오케스트레이터 중의 하나입니다. 오케스트레이터는 도커, 아마존, 쿠버네티스 등 여러 오케스트레이터가 있지만 쿠버네티스가 가장 인기가 있는 이유는 구글에서 쿠버네티스를 개발할 때 구글을 제외하고도 여러 기업이 쿠버네티스 개발에 참여하여 각 기업의 시스템 운영에 관한 기술들이 쿠버네티스에 들어가게 되었고, 이로 인해 타 오케스트레이터 보다 더 기술력 있는 오케스트레이터를 제공하여 사용자들에게 높은 기대와 평가를 받았기 때문입니다. 가상화 기술의 히스토리를 알았으니 쿠버네티스를 이해하고 쿠버네티스의 기능에 대해서 알아보고자 합니다. 쿠버네티스를 이해하기 위해서는 가장 크게 마스터와 노드의 관계, 그리고 기본 오브젝트들(POD, Volume, Service, Namespace, Controller)을 이해해야 합니다. 쿠버네티스의 기본 오브젝트들과 Master-Node 구조를 살펴본 후 쿠버네티스의 기능에 대해 살펴보겠습니다.* Default ObjectsPOD쿠버네티스에서 가장 기본적인 배포 단위이고 컨테이너를 포함하는 단위로 2가지의 특징이 있음- POD 내의 컨테이너는 IP와 PORT를 공유- POD 내의 배포된 컨테이너간에는 디스크 볼륨을 공유VolumnPOD가 기동할 때 디폴트로 컨테이너에 생성되는 디스크는 내용이 유실되는 반면 영구적으로 파일을 저장하여 관리하는 스토리지가 있는데 이것을 Volumn이라고 함Service여러 개의 POD를 서비스하게 도와주고, 로드밸런서를 통해 부하를 분산시키는 역할Namespace쿠버네티스 클러스터 내의 논리적인 분리 단위Controller기본 오브젝트들을 생성하고 이를 관리해주는 역할을 함쿠버네티스는 Master– Node의 관계로서 클러스터라는 개념으로 이루어져 있고, 마스터와 노드를 설명하자면 다음과 같습니다.# Master클러스터 전체를 관리하는 컨트롤러로서 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응함. 대표적으로 kube-apiserver, etcd, kube-scheduler, controller-manager 등으로 구성되어 있음kube-apiserverPOD, 서비스, 복제 컨트롤러 등을 포함하는 api 개체에 대한 데이터를 검증하고 구성etcd클러스터 데이터를 담는 쿠버네티스의 저장소kube-scheduler노드가 배정되지 않은 POD를 감지하고 적절한 노드를 선택, 할당controller-manager컨트롤러를 구동하게 해주는 역할# Node컨테이너가 배포되는 가상머신이나 물리적인 서버머신. 대표적으로 kubelet, kube-proxy, 컨테이너 런타임, DNS 등이 있음kubelet각 노드에서 실행되는 에이전트로 POD에서 컨테이너가 정상적으로 동작하도록 관리kube-proxy네트워크 트래픽을 적절한 컨테이너로 라우팅container runtime컨테이너 실행을 담당하는 소프트웨어DNS쿠버네티스 서비스를 위해 DNS 레코드를 제공 해주는 DNS 서비스마지막으로는 쿠버네티스가 제공하는 기능에 대해서 살펴보겠습니다.자동화된 빈 패킹가용성을 그대로 유지한 채 자원 요구사항과 제약 조건에 따라 컨테이너를 자동으로 배치 자동화된 복구오류가 발생한 컨테이너를 재시작 혹은 컨테이너를 교체하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않음 서비스 디스커버리와 로드 밸런싱쿠버네티스는 POD에게 고유한 IP주소와 DNS 명을 부여할 수 있고, 네트워크 트래픽을 로드밸런싱하고 배포하여서 배포가 안정적으로 이루어질 수 있음Secret과 구성 관리암호나 Oauth 토큰 및 SSH 키 등과 같은 중요 정보를 저장하고 관리하고 컨테이너 이미지를 재구성하지 않고, 애플리케이션 구성을 배포 및 업데이트 스토리지 오케스트레이션로컬 스토리지, 퍼블릭 클라우드 공급자 등 원하는 스토리지 시스템을 자동으로 마운트 자동화된 롤아웃과 롤백애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃을 하고 문제 발생시 변경 사항을 롤백위와 같이 쿠버네티스는 다양한 기술을 기반으로 컨테이너화된 서비스를 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. 그리고 쿠버네티스는 PaaS 시스템에서 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능들을 제공하지만, PaaS 시스템과 다르게 이런 기본 솔루션이 선택적이며 추가나 제거가 쉽다는 특징이 있어 사용자의 선택권과 유연성을 지켜줍니다.최근 쿠버네티스가 서비스 배포 운영의 표준으로 자리 잡아 가고 있고 쿠버네티스의 기술을 바탕으로 많은 기업들이 클라우드 서비스를 제공하고 있기 때문에 많은 오케스트레이터 중에서도 쿠버네티스의 중요성은 높아져 있는 상황입니다.참고 자료1. Kubernetes hompage2. 조대협의 블로그(쿠버네티스#2 - 개념이해)글. 기술지원1팀 최진우 사원

20.09.04
IT·보안
KISA Apache Tomcat 취약점 보안 업데이트 권고

2020년 5월 20일 Apache Tomcat에서 세션 지속성을 통한 원격 코드 실행 취약점(CVE-2020-9484)에 대한 업데이트 버전(Apache Tomcat 10.0.0-M5)을 릴리즈 하였으며, 업데이트 권고는 10.0.0-M1 ~ 10.0.0-M4, 9.0.0.M1 ~ 9.0.34, 8.5.0 ~ 8.5.54 및 7.0.0 ~ 7.0.103 버전 입니다.Apache Tomcat에서는 아래의 4가지 조건이 모두 성립 되어야 취약점에 영향을 받는다고 발표 하였습니다.1. 톰캣 서버의 PersistenceManager가 Filestore를 사용하도록 설정된 경우2. PersistenceManager의 sessionAttributeValueClassNameFilter 항목이 “null”로 설정되거나 공격자가 제공한 객체의 검증이 미흡한 경우3. 공격자가 톰캣 서버의 컨텐츠와 파일의 이름을 설정할 수 있는 경우4. 공격자가 FileStore에서 사용되는 저장 위치와 제어할 수 있는 파일의 상대 경로를 알고 있는 경우따라서 2020년 5월 26일 KISA(한국인터넷진흥원)에서는 취약점 버전을 사용중인 서버의 담당자는 제조사 홈페이지를 참고하여 최신 버전으로 업데이트 할 것을 권고 하였습니다.출처 및 참고자료Tomcat(원문사이트)KISA Apache Tomcat 취약점 보안 업데이트 권고

20.08.31
IT·보안
DELL iDRAC9 보안 업데이트 권고

2020년 7월 Positive Technologies의 Georgy Kiguradze 및 Mark Ermolov는 DELL사에서 제공하는 자사 서버 제품군을 종합적으로 관리하기 위한 통합 관리 플랫폼인 iDRAC9에서 경로 값에 대한 검증이 미흡하여 경로 탐색으로 발생하는 정보노출 취약점을 발견 하였습니다.해당 취약점은 NIST(미국 국립표준기술연구소)의 NVD(National Vulnerability Database)에 게시되었으며, 식별번호 CVE-2020-5366이 할당되었습니다.해당 취약점에 대하여 DELL사는 심각도를 높음으로 분류하고, iDRAC9에 대한 펌웨어 업데이트를 배포하였으며 빠른 업데이트를 권장하였고 KISA에서는 2020년 7월 29일 해당 취약점에 대한 보안 업데이트를 권고하였으며, 영향을 받는 구체적인 버전은 iDRAC9의 펌웨어 버전 4.20.20.20미만의 전 버전이며 해결된 펌웨어 버전은 4.20.20.20이라고 공지 하였습니다.현재 DELL사에서 판매되는 대부분의 서버 제품 군의 경우 iDRAC9을 사용하고 있으므로, 서버 관리 담당자는 현재 DELL 서버가 iDRAC9을 사용 중인지, 사용 중이라면 펌웨어 버전을 확인하여 영향을 받는 버전일 경우 제조사 홈페이지를 통하여 최신 버전의 펌웨어로 업데이트할 것을 권장 합니다.출처KISA 보안 업데이트 권고DELL 취약점 정보DELL 릴리즈 노트

20.08.31
IT·보안
2019 개인정보 보호 상담 사례집 발간

2020년 7월 31일 행정안전부와 한국인터넷진흥원(이하 KISA)은 국민의 개인정보 보호 인식 제고를 위해 개인정보침해 신고센터에 접수된 개인정보 침해 상담·신고 주요 사례를 소개하는 ‘2019년 개인정보 보호 상담 사례집’을 발간하였습니다.KISA는 2019년도 개인정보침해 신고센터에 접수된 개인정보 침해 신고 및 상담 접수 건수는 159,255건으로 전년도 164,497건에 비해 3.2%로 감소 하였고, 2019년 개인정보 침해 신고·상담 접수 유형을 살펴보면 주민등록번호 등 타인 정보의 훼손·침해·도용이 134,000여건(약 84%)이고, 신용정보 관련 문의 등 정보통신망법 적용 대상 외 관련건이 8,700여건(약 5.5%)으로 두 유형이 전체 89.5%를 차지하며 2018년과 마찬가지로 가장 큰 비중을 차지하였다고 밝혔습니다.KISA 2019 개인정보 보호 상담 사례집 개인정보 침해 신고 및 상담 세부 내용중 주민등록번호 처리 및 관리와 관련한 신고·상담이 꾸준하게 제기되고 있으며 개인정보보호법은 법률 또는 대통령령에서 구체적으로 처리를 요구하거나 허용하는 경우에 주민등록번호를 처리할 수 있고, 주민등록번호가 분실·도난·유출·위조·변조 또는 훼손 되지 아니하도록 암호화 조치를 통하여 안전하게 보관하여야 한다고 규정하고 있으나 홈페이지 주민등록번호 노출, 홈페이지 고충 처리 시 주민등록번호 수집 등으로 향후 개인정보처리자가 주민등록번호 처리 시 처리 근거 여부나 암호화 조치에 대한 인식 제고가 더욱 필요한 것으로 보인다라고 밝혔습니다.DB암호화, DB접근제어 등 데이터베이스 보안 관련된 사례로는 임시 개인정보취급자의 사용자 계정 관리(3-6) 항목으로 신시웨이 고객사에게도 다수 발생하는 사례중 하나 입니다.개인정보처리시스템에 접근하는 사용자는 1인 1계정을 사용하여 계정이 공유 되지 않도록 각별히 주의 하여야 하며 인사 이동, 퇴직, 휴직등으로 사용자가 더 이상 개인정보를 처리 하지 아니하면 DB 접근제어 페트라를 통해 해당 해당 계정이 더 이상 개인정보처리 시스템에 접근 하지 못하도록 하여야 하고, 개인정보취급자에게는 페트라를 통하여 최소의 권한만 부여 하여야 합니다.출처행정안전부·한국인터넷진흥원 「2019년 개인정보 보호 상담 사례집」

20.08.31
IT·보안
CORS (Cross-Origin Resource Sharing) 이슈

CORS(Cross-origin resource sharing) 이슈는 웹 개발 초기에 누구나 한 번쯤 겪을 수 있는 상황입니다. 필자의 경우 기존 개발 환경에서 vue.js를 도입 하였을 때 아래와 같은 경고 문구를 보며 당황했던 기억이 있습니다. 이번 기회에 경고 문구를 뜯어보며 CORS에 대해 한 발짝 다가가 볼까 합니다.Access to XMLHttpRequest at ‘http://192.168.xxx.xxx:8080/api/sign/login’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. 흔하게 발생할 수 있는 전체 경고 문구는 위와 같습니다. 하나씩 구분해서 살펴 보면Access to XMLHttpRequest at ‘http://192.168.xxx.xxx:8080/api/sign/login’ 현재 웹 페이지에서 XMLHttpRequest를 사용해 ‘http://192.168.xxx.xxx:8080/api/sign/login’에 정보를 요청하고자 접근(access) 했습니다.from origin ‘http://localhost:8080’ has been blocked by CORS policyXMLHttpRequest를 작성한 파일의 출처(origin)는 ‘http://localhost:8080’이고, XMLHttpRequest의 사용은 CORS 정책에 의해 막혔습니다.Response to preflight request doesn’t pass access control check 사전 요청(preflight request)이 접근 제어 확인을 통과하지 못했고,No ‘Access-Control-Allow-Origin’ header is present on the requested resourceAccess-Control-Allow-Origin’이란 헤더가 요청하고 있는 자원(resource)에 없기 때문입니다. 1. 자원(resource)자원은 HTTP 요청 대상을 말하며 문서, 사진등 어떠한 형태든 될 수 있습니다. 자세한 내용은 잘 정리된 곳이 있으니 참고 하시기 바랍니다. (참조 : MDN – 웹 리소스 식별 ) 2. 출처(origin)출처는 CORS 정책의 적용 기준이 됩니다. A서버 자원이 B서버 자원을 요청하는 상황에서 A, B서버가 서로 다른 서버이면 자원의 출처가 다르다고 판단하여 CORS 정책을 적용합니다. 웹은 프로토콜, 호스트, 포트가 같아야 동일한 출처로 간주하는데 이를 SOP(Same-Origin Policy) – 동일 출처 정책 – 이라 하며, CORS 정책의 근간이 됩니다. CORS 정책은 SOP에 예외를 두는 셈입니다. http://blog.sinsiway.com/trend/post.html과 출처(origin) 비교http://blog.sinsiway.com/trend/ittrend/post.html요청 성공경로http://blog.sinsiway.com/inside/post.html요청 성공경로https://blog.sinsiway.com/trend/post.html요청 실패protocolhttp://blog.sinsiway.com:81/trend/post.html요청 실패porthttp://rnd.sinsiway.com/trend/post.html요청 실패host 3. 사전 요청(Preflight request)사전 요청은 CORS 정책의 확인 시점입니다. 사전 요청은 먼저 Simple Request 에 해당하지 않는 요청을 말합니다. Simple Request의 조건은 이렇습니다. 1) HTTP Method – GET / HEAD / POST2) 사용자 정의 헤더(자동 설정 헤더 제외) – Accept / Accept-Language / Content-Language / Content-Type3) 헤더 Content-Type의 값 – application/x-www-form-urlencoded, multipart/form-data, text/plain 사전 요청은 CORS 확인을 위해 실제 요청 전에 자동 수행하는 요청으로 OPTIONS 메소드를 사용합니다. ‘Access-Control-Request-Method’, ‘Access-Control-Request-Headers’ 등의 헤더에 CORS 조건에서 사용할 메소드 등을 서버에 알려주고 어떻게 응답하는지 먼저 확인하는 것입니다. 서버의 응답에 따라 실제 요청의 차단 여부가 결정됩니다. Simple Request에 해당하더라도 CORS와 무관한 것은 아닙니다. 단지 사전 요청(Preflight request)이 발생하지 않을 뿐입니다. 예를 들어 HTTP Method – POST에 Content-Type – ‘application/json’로 요청하였다면, Simple request에 해당하지 않기 때문에 사전 요청이 발생합니다.요청 받은 서버에 CORS 조치가 없다면, 실제 요청(POST)까지 가지 않고 끝납니다.4. ‘Access-Control-Allow-Origin’ 헤더CORS 정책에 허용할 출처를 명시하는 헤더입니다. 3번에서 언급한 “서버의 응답”에 해당합니다. 서버는 응답 헤더에 ‘Access-Control-Allow-Origin’와 허용할 출처(origin) 정보를 입력하여 CORS 정책을 허용합니다.출처는 ‘Access-Control-Allow-Credentials: true’가 아니라면 와일드 카드(*)도 가능 합니다.끝으로 조치 방안입니다. 경고 문구 기반 원리 이해가 목적이었기 때문에 해결책은 간단하게 요약 하고자 합니다. 우선 해결책의 기본 방안은 서버 측에서 CORS 작업을 하는 것입니다. 익스프레스, 스프링 등 프레임워크 차원에서 기능이 제공되고 있습니다.express – https://expressjs.com/en/resources/middleware/cors.htmlSpring framework – https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/cors.html당장 개발에 영향을 받는 프론트엔드에서 조치할 방안으로는 크롬 브라우저에 옵션을 달아서 실행하거나, 개발 환경 Local Proxy (https://webpack.js.org/configuration/dev-server/) 를 세우는 방법 등이 있습니다.“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –disable-web-security –user-data-dir=”C:\chrome”참고 자료 : 모질로 공식 홈페이지(교차 출처 리소스 공유)

20.08.31