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

본문바로가기

PR

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

IT·보안
문자열 처리 함수 strstr, strcasecmp Tip

C/C++ 개발을 하면서 문자열 처리 함수를 사용할 때 원치 않는 결과를 얻는 경우가 있습니다. 이러한 데에는 여러 가지 상황이 있지만 가장 많이 범할 수 있는 상황은 고려하지 않았던 상황이 발생한 경우와 함수 내부 동작을 정확히 알지 못하는 경우에 문제가 발생합니다.후자의 한 가지 예로 strcasecmp 함수를 들 수 있습니다. 이 함수의 내부 동작을 정확히 아는 개발자가 많지는 않을 것입니다. “_”(95)와 “A”(65) 두 문자열을 strcasecmp로 비교하면 어느 문자열이 크다고 나오는지 아시나요? 대부분의 개발자들은 아스키코드 표에 따라 “_”가 “A” 보다 크다고 이야기하겠지만 결과는 반대입니다.strstr : 스트링 안에서 원하는 스트링을 찾는 함수strcasecmp : 비교할 스트링들의 알파벳을 소문자로 변환하여 문자열 비교하는 함수example 1. strstr로 IP 리스트에서 IP를 제대로 찾아오지 못하는 문제.[ 실행결과 ]192.168.10.40위와 같은 경우 찾고자 하는 IP는 192.168.10.4인데, 192.168.10.40를 리턴합니다. 원인은 ip의 길이와 상관없이 문자열을 찾은 것입니다. 이런 케이스에서 원하는 결과를 얻기 위해서는 문자열 길이까지 함께 비교해줘야 합니다. 이러한 문제를 해결하기 위해서는 길이까지 비교하도록 조건을 추가하면 정확한 값을 얻을 수 있습니다.example 1. 대문자로 정렬된 스트링 배열에서 bsearch시 strcasecmp로 키워드를 못 찾는 문제[ 실행 결과 ]input : d_ | find: null실행 결과를 보면 “D_”를 찾아야 하는데 찾지 못합니다. 문제의 원인은 strcasecmp를 사용한 것입니다. strcasecmp는 비교할 문자열들을 소문자로 변환 후 비교합니다. 이때 알파벳만 소문자로 변환하기 때문에 문제가 발생한 것입니다. ‘_’의 아스키코드(95)는 ‘I’의 아스키코드(73) 값보다 큽니다. ‘I’를 소문자로 변경하면 ‘I’는 ‘i’(105)가 되어 ‘_’보다 큰 값이 됩니다. 결론적으로 input값 “_d”로 bsearch를 수행했을 때 “_D”를 찾아야 되는데 찾지 못하게 되는 것입니다. strcasecmp는 소문자로 변환해서 대소 비교하기 때문에 알파벳이 아닌 기호들은 소문자로 변경하면서 본의 아니게 알파벳보다 값이 커지는 경우가 있어 발생한 문제입니다.이러한 경우에는 대문자로 이뤄진 스트링 배열에서 bsearch로 찾을 때 찾고자 하는 값을 대문자로 변경 후 strcmp로 비교하면 됩니다. 글. 기술연구소 | 윤 건

20.12.08
IT·보안
암호화 패딩(Padding) & Base64 Encoding

블록암호화(CBC, ECB, CFB, OFB)는 평문에 연속되는 Key Stream을 적용하여 1bit씩 암호화하는 스트림 암호화와 달리 블록 단위로 암호화가 이뤄지게 된다. 블록 암호화에는 CBC, ECB, CFB, OFB 모드가 있고 이때 CFB, OFB는 블록 암호화를 스트림 암호화처럼 구성해 평문과 암호문의 길이가 같기 때문에 패딩이 필요 없지만, CBC, ECB는 암호문이 블록의 배수가 되기 때문에 복호화 후 평문을 알기 위해서 Padding을 사용해야 한다. 즉, 패딩(padding)이란 암호화 하고자 하는 데이터가 블록의 길이보다 부족할 경우 패딩을 사용하여 완전한 블록단위로 만들어준 후 암호화를 해야 한다는 것이다.테스트 결과에서 보이듯 OFB모드에서는 원본 데이터와 암호화 데이터 길이가 같기 때문에 패딩이 필요 없으나 CBC모드는 블록의 배수가 되기 때문에 패딩이 필요한 것을 확인할 수 있다.패딩(Padding)의 종류제로 패딩(Zero Padding, Null Padding)패딩이 필요한 부분을 0으로 채우는 방식이며 메시지 끝 부분에 0이 포함되어 있을 경우 어디까지가 데이터이고 어디까지가 패딩인지 구분이 되지 않기 때문에 보통 사용되지는 않는다.Petra Cipher의 Zero Padding 처리 방법 - enc[일반 데이터 + Zero Padding] + trailer - trailer에는 일반 데이터의 Length 정보가 들어가 있다. - 데이터의 Legnth 정보가 들어가 있는 이유는 일반 데이터의 제일 마지막 데이터가 ‘0’인 경우를 고려하여 Trailer를 붙인 것이다.비트 패딩(Bit Padding)패딩이 필요한 부분은 0으로 채우되, 최상위 비트는 1로 채우는 방식이며 최상위 바이트는 16진수로 80이 된다.(2진수로는 1000 0000)즉, 맨뒤에서부터 앞으로 오면서 1이 나올 때 까지를 패딩으로 구분하며 메시지 길이가 블록 크기의 배수여서 패딩이 필요하지 않은 경우에는, 메시지의 일부를 패딩으로 판단하게 된다. 위와 같은 문제는 패딩을 위한 하나의 블록을 둠으로써 해결할 수 있으나, 최악의 경우 expansion ratio가 2가 된다.(하나의 블록 크기의 메시지를 보내기 위해서 하나의 블록 크기의 패딩을 붙여야 한다.)8byte 기준으로 사용을 하며 평문이 블록 크기의 배수가 되지 못하면 필요한 바이트 값만큼 부족한 부분을 채운다.[PKCS5 패딩(PKCS5 Padding) = 8byte 기준](데이터가 5byte 및 4byte인 경우)(데이터가 8byte인 경우)16byte 기준으로 사용을 하며 평문이 블록 크기의 배수가 되지 못하면 필요한 바이트 값만큼 부족한 부분을 채운다.[PKCS7 패딩(PKCS7 Padding) = 16byte 기준](데이터가 10byte인 경우)(데이터가 16byte인 경우)인코딩(Encoding)인코딩(Encoding)은 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해서 다른 형태나 형식으로 변환하는 처리 혹은 그 처리 방식을 말한다.Base64란 Binary Data를 Text로 바꾸는 Encoding(binary-to-text encoding schemes)의 하나로써 BinaryData를 Character set에 영향을 받지 않는 공통 ASCII 영역의 문자로만 이루어진 문자열로 바꾸는 Encoding이다.Base64를 글자 그대로 직역하면 64진법이라는 뜻이다. 64진법은 컴퓨터한테 특별한데 그 이유는 64가 2의 제곱수 64=2^6이며 2의 제곱수에 기반한 진법 중 화면에 표시되는 ASCII 문자들로 표시할 수 있는 가장 큰 진법이기 때문이다.(ASCII에는 제어 문자가 다수 포함되어 있기 때문에 화면에 표시되는 ASCII문자는 128개가 되지 않는다.) 변경하는 방식을 간략하게 설명하면 Binary Data를 6bit씩 자른 뒤 6bit에 해당하는 문자를 아래 Base64 색인표에서 찾아 치환한다.(실제로는 Padding을 더해주는 과정이 추가된다.)Base64 Encoding 특징· 2진 데이터를 ASCII 형태의 텍스트로 표현 가능하다.· Web 인증 중 기본 인증에 사용한다.· 끝부분의 padding(==) 식별 가능하다.· 64개의 문자 영문 대(26), 영문 소(26), 숫자(10),+,- 를 사용한다.단, 000000이 A로 변한다. 기본 원리는 간단한다. 문자열 -> ASCII binary -> 6bit Cut -> base64 encoding 방식으로 진행이 된다. 그러나 한 가지 문제가 있다. 모든 문자열이 3개씩 남김 없이 끊어지진 않는다는 것이다. 그래서 Padding을 사용하여 빈자리를 채운 후 인코딩을 하게 된다.참고자료· 해쉬넷(블록암호) : http://wiki.hash.kr/index.php/블록암호· 위키피디아(Padding) : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation https://en.wikipedia.org/wiki/Padding_(cryptography)#Bit_padding· 위키피디아(Base64) : https://en.wikipedia.org/wiki/Base64글. 기술지원 2팀 | 정종찬

20.12.07
IT·보안
Java Object to CSV

Jackson 라이브러리를 사용하면 자바 객체에 담긴 내용을 Json 뿐만 아니라 CSV(Comma-Separated Values)로도 전환 할 수 있습니다. CSV는 엑셀로 파일을 바로 열어보려는 요구에서 주로 사용 되는데 자바 객체에 담긴 내용을 CSV로 전환하고 파일로 저장하는 방법을 알아 보고자 합니다.pom.xmljackson-databind, jackson-dataformat-csv를 추가한다.그러나 jackson-databind에는 jackson-core, jackson-annotation 의존성이 있어, jackson-databind 만 있어도 된다.자바 객체에서 CSV 파일 생성CSV 형식은 데이터베이스 테이블처럼 열(Column)과 행(Row)으로 표현된다. 자바 객체를 리스트로(java.util.List)로 전달하면, 데이터를 담고 있는 변수로 컬럼을 구성하고 리스트로 들어오는 데이터를 행 단위로 써 내려가는 식이다. Java Object(VO)변수 위에 @JsonProperty("제목")으로 CSV Header에 해당하는 컬럼명을 별도 지정할 수 있다. @JsonPropertyOrder로 컬럼의 순서도 바꿀 수 있다. @Getter @Setter도 달아준다.CsvMapper, CsvSchemaJSON에서 ObjectMapper를 사용한 것 처럼, CSV는 CsvMapper를 사용한다. CsvSchema로 원하는 형식을 잡아준다.파일 생성파일을 준비하고 ObjectWriter로 리스트 데이터로 파일을 작성한다.CsvMapper에서 바로 파일로 내려쓰는 방법도 있지만, OutputStreamWriter에서 인코딩(MS949)을 설정하여야 UTF-8로 저장해 둔 한글을 엑셀에서 정상적으로 볼 수 있다.`.writeAll(responseVoList)` 스키마에 넘겼던 객체의 리스트 인스턴스를 넘겨주면 끝이지만, 파일이 아닌 문자열로 받고 싶다면, JSON처럼 writeValueAsString을 쓸 수도 있다`csvMapper.writer(csvSchema).writeValueAsString(responseDtoList);`적용글. SIGN팀 | 류대석

20.11.26
IT·보안
새로운 웹 기능 WebAssembly

2018년 8월경 우연히 Chrome Dev Summit 2017 발표를 시청하면서 웹 브라우저의 새로운 기능이 추가되고 있는 상황을 알게 되었는데 그 당시에는 웹 브라우저에 대한 새로운 기술 프로젝트들이 시도되고 있다는 느낌과 흥미로운 주제 정도로만 느껴졌었습니다. 그러나 그로부터 2년이 지난 지금 WebAssembly는 점점 웹에서의 영향력이 커지게 되고 있는 것을 보고 WebAssembly에 대해 좀 더 자세히 알아보게 되었습니다.WebAssembly 탄생 배경WebAssembly(약칭: WA, Wasm)가 탄생하게 된 배경은 과거 Web 기반 어플리케이션의 한계 즉 브라우저상에서 동작하는 프로그램들의 성능 때문이었습니다. 그래서 많은 사람들은 Web 브라우저상에서 네이티브 환경처럼 동작하는 프로그램 성능을 구현하기 위해 많은 노력을 하기 시작하였는데 대표적인 프로젝트가 Mozilla asm.js 그리고 Google Native Client(PNaCI/NaCI)가 대표적인 프로젝트입니다.2017년 2월 28일, 4개의 주요 브라우저 업체들은 WebAssembly의 MVP(Minimum Viable Product)가 완료되었다는 합의에 이르렀고, 이는 브라우저에서 안정적인 버전을 지원하기 시작했으며, 그 후 2019년 12월, W3C는 HTML, CSS, Javascript 외 WebAssembly을 4번째 언어로 공식 권고하였고 이로써 Web 환경에 큰 변화가 시작되었습니다.WebAssembly 란?Wasm(WebAssembly)은 새로운 유형의 바이너리 코드이며, Wast(WebAssembly text format) 또는 C, C++, Java, RUST, Golang 등과 같이 다양한 언어로 작성된 것을 컴파일 과정을 통해 Wasm 바이너리 코드를 생성하여 이를 브라우저에서 실행할 수 있도록 하는 새로운 유형의 코드 입니다이로써 Wasm은 웹 브라우저에서 여러 언어로 작성된 코드를 네이티브에 가까운 속도로 실행할 수 있는 길을 제공 하였습니다. 그 외에도 W3C 웹어셈블리 커뮤니티 그룹에서는 Wasm에 대해 다음과 같은 목표를 가지고 있는데 첫번째는 다양한 플랫폼에서 사용할 수 있고 두번째는 디버깅이 가능해야 하며 세번째는 보안성을 유지 해야고 마지막 네번째는 이전 버전과의 호환성을 유지하도록 하는 목표를 가지고 있습니다.1. C/C++로 작성된 코드를 Emscripten(clang + LLVM) complie toolchain 컴파일 요청2. Emscripten이 컴파일 결과를 받아 .wasm 바이너리로 변환 시켜줍니다. $emcc hello_sinsiway.c -s WASM=1 -o hello_sinsiway.wsam3. Wasm는 그 자체로 DOM에 접근할 수가 없으므로, 자바스크립트의 접착제 코드[fetch(), Webassembly.compile(),WebAssebly.Instance()]와 HTML에 연결해주는 과정을 거치면 브라우저에서 실행 가능하게 됩니다.현재 Wasm는 이식성과 관련해 다양한 브라우 및 플랫폼에서 지원하고 있으며, 조금 더 시간이 지나면 호환성에 대한 부분도 많이 개선될 것으로 보입니다.WebAssembly 적용 사례현재 Wasm 적용한 프로젝트는 100여 개가 있고, 현재도 새로운 프로젝트들이 생겨나고 있습니다. 그중 대표적인 사례로는 AUTODESK로 AUTODESK는 AutoCAD 소프트웨어를 웹 브라우저에서도 사용할 수 있게 하려고 Flash를 사용하기도 했고, HTML5와 Javascript의 조합을 사용하기도 했습니다.그러나 기능 및 성능에 제약이 있고 코드를 다시 재작성해야 하는 문제가 발생하게 되었는데 WebAssembly를 사용하면서 35년 전에 작성된 AutoCAD Core C++ Code를 재사용하여 AutoCAD 웹 앱으로 성공적으로 전환하였습니다.AutoCAD 웹 앱 구조(Build the future of the web with WebAssembly and more (Google I/O '18))AutoCAD Web AppMS Blazor는 WebAssembly를 이용하여 클라이언트 웹 개발에 Javascript 대신 C#코드를 사용하여 웹 UI를 빌드할 수 있도록 하였으며 .NET 라이브러리를 그대로 활용할 수 있게 하여 .NET개발자로 하여금 플랫폼 확장성을 높일 수 있게 하였습니다.WebAssembly는 C++,C#, Java, Go, Rust 언어를 사용하는 웹 어플리케이션을 개발해야 하는 상황이라면 혹은 기존에 작성된 C 라이브러리를 웹에 적용할 때도 효과적인 입니다. 또한, 응용 프로그램 배포가 브라우저로 제한되고 동시에 가능한 모든 운영체제를 포함하는 것 역시 큰 장점입니다.글. 프리세일즈·마케팅팀 | 이경진

20.11.05
IT·보안
대용량 처리를 위한 Virtual Scrolling

1990년대의 CS 모델 프로그램들이 2000년대 이후에는 Web 모델 프로그램들로 전환이 많이 이루어지고 있습니다.이러한 추세에 맞추어 대량의 데이터를 처리하는 알고리즘 및 기법들도 새로운 환경에 변화되고 있습니다. 일반적으로 데이터베이스에 저장된 데이터를 조회하여 사용자 화면에 표출할 때 조회한 데이터를 그리드 페이지에 출력하여 페이징 처리하게 되는데 이때 대량의 데이터를 조회하여 출력할 경우 스크롤 이동 시 딜레이 현상이 발생하게 되는데 이러한 현상을 개선하고 최소화하기 위해 Virtual Scrolling 기법이 많이 활용되고 있습니다.우리가 Web browser로 대량의 데이터를 다룰 때 화면에 표기되는 html element들을 오브젝트 개수만큼 생성하게 되면 클라이언트 자원을 많이 소모하게 되고, 이 때문에 브라우저 화면이 멈추거나 부드러운 조작을 할 수 없게 됩니다.Virtual Scrolling은 화면의 보이는 영역만 element들을 생성하고 보이지 않는 영역은 빈 공간으로 두어, 스크롤링 시 내부의 연산을 통하여 다음 element를 추가하고, 기존 element를 제거하여 사용자에게 최적의 퍼포먼스를 제공하는 기법입니다.위의 Virtual Scrolling의 메커니즘을 보면 앞서 말했던 실제 보이는 영역과 가려져 있는 빈 영역이 존재하는 것을 볼 수 있고, 중간에 Padding row라는 영역이 있는 것을 볼 수 있습니다.Padding row는 스크롤링시 다음 보여줄 데이터를 연산하기 위한 과정의 공백을 메우기 위한 여분의 row element로서, 부드러운 화면의 조작을 위해 존재하는 element로 사용자가 실제 스크롤링을 하면 이동한 만큼 다음 보일 row element를 계산하고 새로운 element가 추가되면 기존 있던 element가 제거되어 element의 개수를 유지하게 됩니다. Padding row의 최적화된 개수는 클라이언트마다 다를 수 있습니다.Virtual Scrolling을 구현하기 위한 중요한 요소 중 하나는 row height입니다. 하나의 row element의 높이가 일정하지 않다면 전체 스크롤링 할 수 있는 높이를 구할 수 없게 되고, 전체 높이 값이 일정하지 않다면 스크롤링시 원하는 다음 화면을 기대할 수 없게 됩니다.Virtual Scrolling을 구현 중 빠르게 이동되거나 어떤 지점으로 스크롤링이 바로 돼야 하는 상황을 대비하여 Skip paging이란 기법이 필요한데 Skip paging은 스크롤 중간의 연산 없이 바로 최종 화면의 element만 계산하여 보여주는 기법으로, 이 기법 없이 그리드를 구현하게 된다면 빠른 스크롤링이나 특정 지점 스크롤링시 지연이 발생 될 수 있습니다.결과적으로 이러한 메커니즘들 때문에 사용자는 대량의 데이터를 부드럽게 조작해 볼 수 있으며, 자원 낭비로 인해 화면 멈춤 등의 이슈가 발생하지 않게 됩니다.현재 새롭게 출시를 준비 하는 Petra DataStudio(가칭)은 사용자 및 데이터베이스 정보를 중앙에서 집중적으로 관리하여 기업 내 DB 보안 및 작업의 편의성을 제공해주는 Web bases SQL Tool로 Virtual Scrolling을 적용하여 빠른 렌더링 속도를 자랑하며 작성 또는 사용된 SQL을 조직 사용자 간 공유할 수 있는 특징을 가지고 있습니다. 또한, 다양한 형태의 데이터 출력 리포트를 제공하며 데이터 암호화 지원으로 데이터에 대한 보안성을 강화시켰습니다.Petra DataStudio는 현재 알파 버전에 대한 테스트를 진행하고 있으며, 고객 의견 수렴을 위해 On-Line Open Beta Service를 진행할 예정입니다.글. 데이터스튜디오팀 | 원충의

20.11.04
IT·보안
금융회사에서의 데이터변경 처리 절차(전자금융감독규정)

정보보호란 정보의 훼손·변조·유출 등을 방지하기 위한 기술적 관리 수단을 말하는데 우리가 보호해야 할 정보들은 수많은 곳에 논리적 또는 물리적 형태로 다양하게 저장되어 있습니다.대부분의 정보(데이터)는 Oracle, SQLserver, MySql과 같이 데이터를 속성과 데이터값으로 구조화하는 관계형 데이터베이스(Relational DataBase Management System)에 저장되는데 이러한 정보 등의 훼손·변조·유출을 방지하기 위해 많은 기업들은 시스템 접근, 차단, 감사, 모니터링등 각종 수단을 이용하여 보안 위험을 감지하고 감소, 억제하기 위한 대책을 마련하고 있습니다.이러한 대책 마련 활동들을 정보보안에서는 보안 통제(Security Control)라고 하는데 통제는 유형에 따라 기술적(논리적), 물리적, 관리적 통제 등 다양한 형태의 통제 방법이 있으며 정보보호에서 가장 눈여겨 봐야 할 것은 ISO / IEC 27001, NIST Special Publication 800-53에서 제시한 예방 통제(Preventive controls), 탐지 통제(Detective controls), 교정 통제(Corrective controls) 입니다. 이 세 가지는 시점에 의해 분류한 통제 유형으로 데이터베이스 보안에 대한 필요성을 보여주기도 합니다.예방 통제(Preventive controls)사전에 위험을 억제하기 위한 통제 방법으로 물리적 접근 통제와 논리적 접근 통제로 나뉜다. 데이터베이스 보안 관점에서의 논리적 접근 통제는 비인가자가 정보통신망을 이용하여 데이터베이스에 접근하는 것을 차단하는 것을 말하며 기술적 통제로는 방화벽, 인증, 암호화 등이 있으며 관리적 통제로는 보안정책 수립, 보안 서약, 직무 분리 등이 있습니다.탐지 통제(Detective controls)예방 통제를 우회하여 발생되는 행위를 통제하는 방법으로 보안 위협 및 침해 사고의 발생을 인지하는 시점을 말하고, 데이터베이스 보안 관점의 기술적 통제로는 감사 로그, 알람 발생 등이 있으며 관리적 통제 방법으로는 감사 및 모니터링 등이 있습니다.교정 통제(Corrective controls)탐지된 위협이나 원인을 식별, 분석하여 원상태로 조치하는 시점을 말하며 데이터베이스 보안 관점의 기술적 통제로는 감사 데이터 추적, 식별 관리적 통제로는 데이터 백업,복구 계획 수립 및 정책 계획 재수립 등이 있습니다.이처럼 정보보호에서 가장 처음 시행 되어야 할 통제 방법은 예방 통제이며 탐지 그리고 교정 순입니다. 무엇보다 중요한 것은 통제 유형에 대한 기술적, 관리적, 물리적 조치가 이루어져야 하는데, 신시웨이의 페트라 시리즈는 정보 보호에 있어 예방, 탐지, 교정 통제에 맞는 기술적, 관리적 조치를 제시하고 있습니다.앞서 말했듯이 데이터베이스에는 수많은 데이터가 저장되어 있고, 수 많은 데이터 중에서 개인정보를 가장 민감하게 관리 하고 있습니다. 우리나라 또한 2011년 9월 30일 「개인정보보호법」이 시행되면서 개인정보보호와 처리에 대한 가이드 라인을 제시하고 있습니다.그러나, 개인정보보호법에서의 「표준 개인정보 보호지침」을 준수하였다고 하더라도 개인정보 취급 형태, 업무 등에 따라 기술적, 관리적 조치 방안이 상이 할 수 있기 때문에, 데이터베이스 보안 솔루션 도입에 있어 다양한 Compliance에 대해 기술적, 관리적 조치를 할 수 있는지를 먼저 고려해야 합니다.2020년 5월 19일 전자금융거래의 법률관계를 명확히 하여 전자금융거래의 안전성과 신뢰성을 확보함과 아울러 전자금융업의 건전한 발전을 위한 기반조성을 함으로써 국민의 금융 편의를 꾀하고 국민경제의 발전에 이바지하기 위해 「전자금융거래법」을 일부 개정하고 2020년 8월 20일 시행 되었다.또한 「전자금융거래법」 및 시행령에서 금융위원회에 위임한 사항과 그 시행에 필요한 사항 및 다른 법령에 따라 금융감독원의 검사를 받는 기관의 정보기술부문 안전성 확보 등을 위하여 필요한 사항을 규정 하기 위해 2019년 1월 1일 「전자금융감독규정」을 시행 하였습니다.2013년 12월 3일 「전자금융감독규정」 제 27조(전산원장 통제), 제 28조(거래통제 등)의 “금융기관”을 “금융회사”로 개정하면서 전산원장을 취급하는 은행, 증권, 카드사등의 금융회사는 「전자금융감독규정」 제 27조, 제 28조에 의해 전산원장 변경을 위한 별도의 절차가 필요하며 변경 권한자를 지정하여 결재 승인을 득한 후 전산원장 변경이 실행 되어야 하며, 실행된 내용은 자동으로 기록하여, 그 행위를 추적할 수 있게 5년간 보관 하여야 합니다.제27조(전산원장 통제) ① 금융기관 또는 전자금융업자는 장애 또는 오류 등에 의한 전산원장의 변경을 위하여 별도의 변경절차를 수립·운용하여야 한다.② 제1항의 절차에는 변경 대상 및 방법, 변경 권한자 지정, 변경 전후내용 자동기록 및 보존, 변경내용의 정당여부에 대한 제3자 확인 등이 포함되어야 한다.③ 금융회사 또는 전자금융업자는 대차대조표 등 중요 자료의 계상액과 각종 보조부·거래기록·전산원장파일의 계상액에 대한 상호일치 여부를 전산시스템을 통하여 주기적으로 확인하여야 한다. <개정 2013. 12. 3.>④ 금융회사 또는 전자금융업자는 제3항에 따른 확인 결과 불일치가 발견된 때에는 그 원인 및 조치 내용을 전산자료의 형태로 5년간 보존하여야 한다. <개정 2013. 12. 3.>⑤ 금융회사 또는 전자금융업자는 이용자 중요원장에 직접 접근하여 중요원장을 조회·수정·삭제·삽입하는 경우에는 작업자 및 작업내용 등을 기록하여 5년간 보존하여야 한다. <개정 2013. 12. 3.>제28조(거래통제 등) ① 금융회사 또는 전자금융업자는 사고위험도가 높은 거래에 대하여는 책임자 승인거래로 처리토록 하는 등 전산시스템에 의한 이중확인이 가능하도록 하여야 한다. <개정 2013. 12. 3.>② 금융회사 또는 전자금융업자는 전산원장, 주요정보 또는 이용자 정보 등이 저장된 정보처리시스템에 대한 중요작업 수행 시 책임자가 이중확인을 해야 한다. <개정 2013. 12. 3.>금융회사들은 전산원장변경 요청시 데이터 변경에 대한 근거 문서를 토대로 문서를 작성 하게 되는데 일반적으로 현업의 실무자가 데이터 변경에 대한 근거 문서를 작성하여 IT 부서(IT 담당자)에 전달하면 IT 부서의 담당자는 전산원장변경 요청 SQL을 작성하여 해당 부서 팀장의 결재를 얻은 후 변경 권한자(DBA)에게 SQL 실행을 요청 하고 SQL 실행 후에는 제 3자에 의해 타당성을 검토를 실시합니다.데이터 변경 SQL 작성검증 및 데이터 변경 전/후 데이터 확인페트라 싸인(PETRA SIGN)의 데이터베이스 데이터 변경 기능은 커스텀마이징을 통해 기존에 사용하던 전자 결재 시스템의 근거 문서 연동을 제공 하고 데이터 변경 이력을 관리함으로써 「전자금융감독규정」을 준수하며 예방, 탐지의 기술적 통제 방안을 제공하고 악의적인 데이터 변경과 사용자의 실수를 사전에 예방할 수 있습니다.또한 저장된 전/후 데이터에 대한 암호화 지원으로 데이터의 기밀성을 보장 합니다.그 외에도 페트라 싸인(PETRA SIGN)에는 다음의 기능들이 있습니다. DB 접속 허가 요청서- 세션 차단 규칙에 의해 접속할 수 없는 DB에 대한 접속 권한을 얻기 위해 사용- 결재 문서 작성 시 접속 날짜 및 요일, 시간대, 접속 가능 횟수, 대상 DB 정보를 작성- 접속 횟수는 무제한으로 설정 가능SQL 실행 사전 요청서- SQL 거부 규칙에 의해 실행할 수 없는 SQL에 대한 실행 권한을 얻기 위해 사용- 결재 문서 작성 시 SQL 실행 날짜, 요일, 시간대, 대상 DB 정보와 실행 횟수, 실행하고자 하는 SQL 문장 혹은 SQL 타입을 설정함- 객체 정보로 결재 문서를 작성한 경우 DB 객체 정보 수집이 작업이 선행되어야 함- 실행 횟수는 무제한으로 설정 가능SQL 실행 소명서- SQL 사후 소명 혹은 SQL 즉시 소명 규칙이 설정된 경우 SQL 실행 사유를 남기기 위해 사용기타 보안 규칙 등록 요청서- DB 접속 통제, SQL 통제 이외의 규칙에 대한 권한을 얻기 위해 사용- 종결된 후 수동으로 보안 규칙을 수정해야 함마스킹 해제 요청서- 마스킹 규칙에 의해 마스킹 처리되어 조회되는 데이터를 마스킹 처리 없이 조회할 수 있는 권한을 얻기 위해 사용사용자 등록 요청서- PETRA ID를 발급받기 위해 사용하는 결재 문서- 본인이 직접 신청하거나 ID가 있는 사람이 대신 신청 가능- 본인 신청은 로그인 화면 사용자 신청 버튼을 통해 작성글. 기술지원 2팀 | 김홍경

20.11.02
IT·보안
보안담당자를 위한 데이터베이스 보안 강화 방법

산업이 발달한 현대 사회는 개인정보, 민감정보, 신용카드정보, 의료정보 등 수많은 정보들이 데이터베이스 내에서 생성과 삭제를 수없이 반복하고 있습니다. 이러한 정보들은 누군가의 표적과 함께 먹잇감이 되고 있고 이 먹잇감을 지키기 위해 많은 기업들은 OS보안, 네트워크 보안, 시스템 보안 등을 이용하여 기술적‧관리적 보호조치를 시행하고 있습니다.그러나 실질적으로 데이터가 저장되는 데이터베이스(DB보안) 보안 조치의 경우 이를 가볍게 또는 안일하게 생각하는 일부 보안담당자 또는 관리자들이 있습니다. 사실 안일하게 생각한다기보다 앞서 말한 OS보안, 네트워크 보안등 전체적인 보안 범위를 설계하고 구축 하다 보니 예산 부족 등의 문제로 데이터베이스는 가장 기본적인 보호 조치 또는 법령에 의한 최소한의 보호 조치만 이루어지고 있는 경우가 종종 발생하며 이러한 일들은 체계와 인프라가 잘 갖추어진 대기업보다는 전문 인력이 부재한 중/소규모의 기업에서 주로 발생 하고 있습니다.2011년 3월 29일 개인정보보호법이 공포되고 2011년 9월 30일 전면 시행되면서 개인정보보호가 강화되고 각종 규제가 많아지면서 과거보다 개인정보에 대한 기술적‧관리적 보호조치가 잘 이루어지고 있지만, 개인정보 침해와 개인정보 유출 사고는 지속해서 일어나고 있습니다. 과거에 데이터베이스 내의 데이터 유출 사례를 보면 대부분 내부자에 의한 의도적인 데이터 유출, 프로그램(시스템) 오류로 인한 데이터 노출이 많았지만, 현대에는 전문 해커에 의한 유출 사고도 빈번하게 발생 하고 있습니다.악의적인 공격으로 인한 데이터 유출 동향 / IBM Security와 Ponemon Institute1「(2020 Cost of a Data Breach Report)」해킹으로 인한 국내 데이터 유출 최근 사례2017년 해커에 의한 해킹으로 사이트 가입자 아이디/비밀번호 13만 2800여건 유출2018년 해커에 의한 해킹으로 쇼핑몰 가입자 개인정보 유출2020년 해커에 의한 해킹으로 교육원 회원 개인정보 유출2020년 해커에 의한 해킹으로 약 412억 건의 금융정보 유출 정보보안팀의 보안담당자라면 BCP(업무 연속 계획)과 DRP(재해 복구 계획)에 대하여 잘 알고 있을 것이고 이러한 계획의 목적 중 하나는 비즈니스의 연속성 및 손실을 최소화하기 위해서 인데 BCP, DRP 계획만큼 중요한 것이 데이터베이스 보안 설계 입니다.만약 데이터베이스가 적절하게 보호 조치되지 않아 데이터 유출 사고가 발생한다면 비즈니스 연속성은 불가능하며 기업의 이미지 훼손, 신뢰도 하락, 재정적 손해 등 수많은 피해가 발생합니다.IBM Security와 Ponemon Institute가 발표한 「2020 데이터 유출 비용 보고서 (2020 Cost of a Data Breach Report)」에 따르면 기업의 데이터 유출 사례 중 80%는 고객개인식별정보(Personally Identifiable Information, PII) 노출 사고로, 기업 당 평균 피해액은 약 45억 9000만 원에 달하고, 2020년 대한민국 기업당 평균 데이터 유출 피해액은 38억 원으로 나타났습니다. 또한, 데이터 유출을 감지한 후 식별하는 데까지 걸리는 기간은 223일, 침해 해소에 걸리는 기간은 78일이라고 발표하였습니다.국가 , 지역별 데이터 유출 근본 원인 분류 / IBM Security와 Ponemon Institute1「(2020 Cost of a Data Breach Report)」이러한 정보 유출 사고를 막기 위해서는 기본적으로 Authentication(인증), Data Protection(데이터 보호), 접근 통제(Access Control), Monitoring(모니터링), Data Encryption(데이터 암호화) 5가지의 방법을 복합적으로 사용하여야 하고 책임추적성(Accountability)을 확보해야 합니다.1. Authentication(인증)접근 통제의 요소는 식별(identification), 인증(Authentication), 인가(Authorization), 책임추적성(Accountability)로 구성되어 있는데 여기서 식별과 인증은 별개로 볼 수 없습니다. 식별은 주체(Client)가 이름, 아이디, 번호등으로 주체의 신원을 주장하는 것이며, 인증은 주체가 주장하는 신원을 검증(확인) 하는 것을 말합니다. 주체의 신원을 확인하는 방법 즉, 인증의 방법(Factor)으로는 지식기반 「Type 1, Something you know (Password, PIN code)」, 소유 기반 「Type 2, Something you have (SMS, Token, Smart card)」, 속성 기반 「Type 3, Something you are, Something you do (Bio, sign)」로 분류되며 3가지의 분류 중 한 가지만 사용한다면 싱글팩터 인증(Single Factor Authentication, SFA) 이라고 하며, 2개 이상의 방법을 사용한다면 투팩터 인증(2 Factor Authentication, 2FA) 이라고 합니다.데이터베이스 보안 강화를 위한 조치- 지식 기반과 소유 기반을 결합한 2FA 인증- LDAP, Active Directory 인증 연동- 데이터베이스 보안 솔루션에서의 사용자 정보(비밀번호)는 SHA-256 이상의 암호화 저장- 데이터베이스 보안 솔루션에서 제공되는 인증 시스템의 이중화- 사용자 비밀번호 복잡도 설정 필수(소문자,대문자,숫자,특수문자 포함 8자리 이상)신시웨이의 데이터베이스 접근 통제 솔루션 「페트라(PETRA)」는 SMS, E-mail, OPT, MOTP와의 연동으로 인증을 강화하고 LDAP, Active Directory 시스템과 연동하여 사용자 인증을 관리 할 수 있습니다. 또한 페트라 자체 인증 서버를 사용할 경우 인증서버를 이중화하여 인증의 가용성을 보장 하며 사용자의 비밀번호는 SHA-256으로 안전하게 저장되고 사용자 인증에 대한 임계치 설정으로 악의적인 비밀번호 입력 및 무차별 공격에 대비할 수 있습니다. 또한, 관리자는 비밀번호가 아닌 별도의 인증서를 통해 관리 콘솔에 접속하므로 관리 콘솔 접속에 대한 보안성이 우수합니다. 2. Data Protection (데이터 보호)데이터베이스 접근 통제에서 데이터 보호는 4가지 관점으로 보아야 합니다.첫번째는 인가되지 않은 사용자나 시스템에 의한 접근을 통제하여 정보 공개·노출을 막기 위한 기밀성(Confidentiality) 유지를 말합니다.두번째는 무결성(Integrity)으로 데이터베이스 접근제어에서의 무결성은 데이터베이스에서의 참조무결성(Referential Integrity)을 말하는 것이 아니라 데이터의 정확성 및 완전성을 보장하고 데이터가 고의적, 악의적으로 변경되거나 훼손 또는 파괴 되지 않음을 보장하는 것을 말합니다.세번째는 인가된 사용자가 데이터베이스에 정상적으로 접속하여 서비스할 수 있도록 가용성(Availability)을 보장하는 것이다.네번째는 주체가 행한 행위에 대한 감사 데이터 변경 또는 훼손 되지 않도록 보호 되어야 합니다. 책임추적성(Accountability)은 시스템 내의 각 개인은 유일하게 식별 되어야 한다는 정보 보호 원칙 중 하나로 부인 방지를 가능하게 하고 행위에 대한 책임을 야기할 수 있기 때문에 감사 데이터는 변경, 삭제 등의 데이터 조작이 불가능해야 하며 저장된 데이터 파일이 유출되더라도 그 내용을 확인할 수 없어야 합니다. 또한, 유사시 복구 시스템에 의해서만 복구되어야 합니다.데이터베이스 보안 강화를 위한 조치- 저장된 감사 데이터는 어떠한 경우라도 위/변조 불가- 개인정보, 민감정보(Table , Column)에 대한 식별 및 관리- 운영DB 외 개발 및 테스트 DB에 주요 정보 존재 시 마스킹 필수신시웨이의 데이터베이스 접근 통제 솔루션 「페트라(PETRA)」는 타 솔루션과는 달리 당사가 자체 개발한 메모리 기반의 SOHA DBMS를 사용하므로 세션 유입 시 정책 검색에서 빠른 속도를 자랑하며, Insert Only 감사 테이블 관리로 감사 데이터의 조작이 불가능합니다. 또한, 데이터 파일이 유출 되더라도 별도의 복구 시스템과 엔지니어의 기술 지원 없이는 데이터 복구와 확인이 불가능 합니다. 또한, 조회 값에 대한 데이터 마스킹이 아닌 프로토콜 분석과 결합한 Data Parsing기술을 사용하여 보안성이 우수한 마스킹을 제공합니다.실제로 2018년 A고객사의 인가된 내부 직원이 데이터베이스에 접속하여 불법적으로 데이터 조회 및 변경한 사례가 발생 하였는데 페트라를 통하여 이상징후를 감지 하고 감사 로깅을 추적하여 해당 직원에게 책임을 묻는 사례가 있었습니다. 이와 같이 책임추적성을 보장하기 위해서 감사 데이터는 어떠한 경우라도 위/변조가 불가능 해야 합니다.3. 접근 통제(Access Control)접근 통제는 인증된 주체(사용자)가 필요한 정보에 접근할 수 있도록 하는 기술적 통제 방법을 말하며, 기술적인 통제를 하기 전 보안담당자는 관리적 통제 방안을 먼저 수립하여야 합니다. 관리적 접근 통제에는 정책 설계, 표준화, 절차 수립, 보안인식교육, 훈련 등이 있으며, 관리적 통제에 의해 정책 설계와 업무에 따른 표준화가 설정 되어 있지 않다면, 향후 보안의 홀 발생과 함께 정책 관리의 어려움이 발생하게 됩니다. 데이터베이스 보안 외에도 개인정보보호 관련 내부 관리계획 수립은 한국인터넷진흥원에서 제공하는 「개인정보의 기술적ㆍ관리적 보호조치 기준 해설서」를 참고 하면 많은 도움이 됩니다.데이터베이스 보안 강화를 위한 조치- 주체(ID), 언제(통제 기간 등), 어디서(IP, Program 등), 객체(ID, Table, Column 등), 행위(Select, DML, DCL 등) 등을 세부적인 정책 설정- 인증과 별도로 정책 부여시 사용자와 IP를 1:1로 맵핑하여 주체에 대한 정확한 식별(책인추적성 강화)- 일반 사용자에 대한 데이터베이스 공통 계정 사용 금지- 반드시 White list 보안 정책 설정신시웨이의 데이터베이스 접근 통제 솔루션 「페트라(PETRA)」는 개인, 조직, 그룹별 정책 설정으로 주체에 대한 권한 설정이 가능하며 접근 가능 시간, OS계정, DB계정, 터미널명, 클라이언트명등의 세부 속성 설정이 가능합니다. 또한 DML, DCL, DDL등 SQL TYPE별 설정으로 SQL 명령어 통제에 대한 보안성이 우수 합니다. 페트라는 ISMS-P, 방송통신위원회 감사, 금융감독위원회 감사, 행정안전부 감사 등 여러 감사를 통하여 데이터베이스 보안 제품으로서의 우수성을 확인하였습니다.4. 모니터링(Monitoring)접근 통제에 대한 정책을 효과적으로 설정하였다면 실질적으로 차단 세션, 차단 SQL등에 대한 감사 모니터링이 진행 되어야 합니다. 세부적으로는 세션, 결과값등의 임계치 설정에 대한 알림을 수신 받아야 이상 징후를 식별하고 탐지할 수 있습니다. 또한 모니터링과 별개로 감사 현황에 대한 데이터 및 리포트를 활용하여 월간, 분기, 연간 보고서를 작성하고 보안 평가를 진행해야 합니다.데이터베이스 보안 강화를 위한 조치- 사용자별 접속/차단 통계 리포트 생성 후 변화 추이 분석- 개인정보 및 민감정보에 대한 접근 이력 관리- 실시간 경보 알람 설정- 접속 기록 월 1회 이상 점검- 관리자에 의한 정책 변경 이력 관리신시웨이의 데이터베이스 접근 통제 솔루션 「페트라(PETRA)」는 설정에 따라 SMS, E-mail 등 알림을 제공하고 있으며, 설정 기간에 따른 정형 및 비정형 보고서를 제공 하고 있습니다. 페트라 차기 버전에서는 모니터링 강화를 위해 그래프를 통한 실시간 현황 및 이상징후 탐지 기능을 제공합니다.5. 데이터 암호화(Data Encryption)개인정보의 안정성 확보조치 기준에는 “제7조(개인정보의 암호화) 개인정보처리자는 고유식별정보, 비밀번호, 바이오 정보를 정보통신망을 통하여 송신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 하며 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다.” 라고 명시 하고 있습니다. 또한 개인정보보호법 제23조에 따라 민감정보를 처리하는 경우 안전조치의무에 따라 안전성확보에 필요한 기술적, 관리적 및 물리적 조치 위해 암호화를 해야 하는데 민감정보란 사상, 신념, 노동조합, 정당의 가입, 탈퇴, 정치적 견해, 건강, 성생활 등에 관한 정보, 그 밖에 정보주체의 사생활을 현저히 침해할 우려가 있는 개인정보(유전정보, 범죄경력자료에 해당하는 정보)를 말합니다.데이터베이스 보안 강화를 위한 조치- 안전한 알고리즘 사용(패스워드의 경우 SHA-256 이상의 일방향 암호화 사용)- 국정원 검증필 암호화 모듈 사용- 별도의 키 관리 서버 구축 및 안전한 키 보관- 반드시 White list 보안 정책 설정신시웨이의 데이터베이스 암호화 솔루션 「페트라 사이퍼(PETRA CIPHER)」는 컬럼 단위 암호화를 통해 개인정보를 보호하며, C언어 기반 모듈 사용으로 빠른 속도로 암·복호화를 진행합니다. 또한, 자사 솔루션인 데이터베이스 접근제어 PETRA와의 완벽한 연동을 통해 실제 IP 기반의 접근 통제를 가능하게 하며, 국제 CC인증 획득으로 페트라의 보안성을 검증 받았습니다. ISO/IEC 17799에서는 “정보는 다른 중요한 비즈니스 자산과 같이 가치를 가진 자산이며, 따라서 적절하게 보호되어야 한다” 라고 정의하고 있습니다.즉, 데이터베이스에 저장된 정보는 개인의 자산이자 기업의 자산이기도 합니다. 데이터베이스 보안에서 제품의 완성도와 기능, 엔지니어의 기술력과 대응력도 중요하지만, 보안담당자는 데이터베이스 보안 패치와 지속적인 취약점 진단을 실시하고 불필요한 기능 및 계정을 최소화 하여 데이터베이스 보안성을 최대한 강화하면서 민감정보 및 주요정보를 최소화하여 데이터베이스의 가치는 극대화 하여야 합니다.또한, 주기적인 데이터베이스 감사 활동 및 모니터링, 데이터베이스 액세스 관리, 데이터베이스 암호화에 더욱더 신경 쓴다면 데이터베이스 보안은 한층 더 강화될 것입니다. 개인정보 처리에 대한 계획 수립과 방법을 고민하는 보안담당자라면 유형1, 2, 3별 적용 대상과 안전조치 기준이 서로 상이하니 「개인정보포털>자료마당>지침자료에서 개인정보의 안전성 확보조치 기준(제2019-47호) 해설서(2019.06, 개정)」을 반드시 참고 하여야 합니다.데이터베이스 보안 관리에 최적화된 신시웨이 PETRA 시리즈는 신시웨이 홈페이지(www.sinsiway.com) 또는marketing@sinsiway.com 으로 연락 주시면 보다 자세히 확인 하실 수 있습니다. 신시웨이가 보안담당자에게 추천하는 유용한 사이트개인정보의 안전성 확보 조치 기준개인정보보호법2020 Cost of a Data Breach Report데이터베이스 보안 가이드라인개인정보보호 포털(자료마당)한국인터넷진흥원개인정보보호위원회개인정보침해 신고센터

20.10.30
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