-
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
PR
신시웨이의 최신 소식과 다양한 IT/보안 정보를 제공합니다.