박종명의 아름다운 개발 since 2010.06

한 미국인 사업가가 의사의 지시에 따라 멕시코의 작은 해안 마을에서 휴가를 보내고 있었다.
첫날 아침, 그는 사무실에서 온 긴급한 전화를 받은 뒤 잠을 이룰 수 없어 머리를 식히려고 부둣가로 나갔다.

부두에는 달랑 어부 한 명이 탄 작은 배가 대어져 있었는데, 그 배 안에는 큼지막한 황다랑어 몇 마리가 있었다.
미국인은 그 멕시코 어부에게 물고기가 아주 훌륭하다고 칭찬을 했다.

“이것들을 잡는 데 얼마나 걸리셨나요?” 미국인이 물었다.
“얼마 안 걸렸수다.” 멕시코인은 놀라울 정도로 완벽한 영어를 구사하였다.
“바다에 더 오래 있으면서 고기를 좀 더 많이 잡지 그러셨어요?” 다시 미국인이 물었다.
“가족을 먹여 살리고 친구들에게도 몇 마리 나눠 줄 만큼 잡았는걸.” 멕시코인은 물고기들을 바구니에 담으면서 말했다.
“하지만…, 남는 시간에는 뭘 하시는데요?”
멕시코인은 미국인을 올려다보더니 미소를 지었다. 
“늦잠 자고, 물고기 좀 잡고, 아이들과 놀아 주고, 아내 줄리아와 낮잠을 잔다우. 그러고는 저녁마다 마을을 어슬렁거리다 포도주도 마시고 친구들과 기타를 치면서 놀지. 살고 싶은 대로 살면서 내 딴에는 바쁜 몸이라우.”

미국인은 웃더니 일어났다. 
“저는 하버드 MBA 출신으로 아저씨를 도와드릴 수 있습니다. 아저씨는 물고기 잡는 데 더 많은 시간을 투자하고, 그 수익금으로 더 큰 배를 살 수 있습니다. 그러면 머지않아 어획량이 늘어나 배를 몇 척 더 살 수 있을 거고, 나중에는 고기잡이 선단을 갖게 될 거구요.”

그는 계속했다. 
“잡은 고기를 중간 상인한테 파는 대신 소비자에게 직접 팔다가 나중에는 통조림 공장을 여는 거죠. 결국에는 아저씨가 제품과 가공, 유통까지 손에 넣게 되는 겁니다. 물론 이 작은 어촌 마을을 떠나 멕시코시티로 옮겨야 할 거고, 그 후에는 로스앤젤레스 그리고 뉴욕까지 진출하는 겁니다. 뉴욕에서는 유능한 경영진과 호흡 맞춰 계속 사업을 확장하며 운영할 수 있을 겁니다.”

“그 모든 일을 이루는 데 얼마나 걸리겠수?” 멕시코인 어부가 물었다. 
이 말에 미국인이 대답했다. 
“15년에서 20년 정도요. 길어야 25년이죠.”

“그다음엔 어떻게 되우?”
미국인은 웃으면서 말했다. “그게 가장 중요한 부분이죠. 때가 되면 주식을 상장한 후 회사 주식을 팔아서 엄청난 부자가 되는 겁니다. 아마 수백만 달러는 벌게 될 거예요.”
“수백만 달러? 그러고 나서는?” 

“그다음엔 은퇴한 후 작은 어촌 마을로 가서 늦잠 자고, 물고기 좀 잡고, 아이들과 놀아 주고, 아내와 낮잠 자고, 저녁에는 어슬렁어슬렁 마을이나 돌아다니며 포도주도 마시고 친구들하고 기타 치며 노는 거죠….”

- 나는 4시간만 일한다(팀 페리스)

과연.. 무엇을 위해 치열해야 하는가...

예전 자료를 보다 우연히 기술사 면접 질문을 정리한 글을 발견했다.

2016년 4월 28일...
108회 정보관리기술사 면접이었으며, 면접 이후 기억에 의존해서 정리한 글이다.

당시 면접 대기실에는 정보분야 뿐만 아니라 다양한 공학분야 기술사들이 같이 면접 대기를 하고 있었다.
나이 지긋해 보이는 분들이 꽤 있었던 것으로 기억한다.

면접관은 총 3분이었으며, 대학교수님과 선배 기술사로 구성되었다고 알고 있다.
편의상 3분을 차례대로 왼쪽분, 중간분, 오른쪽분으로 구분하였다.

아래와 같은 질문들이었는데, 당시 면접 이후 기억에 의존해서 작성되었던 거라 몇 가지 놓친것도 있으리라.

처음 시작...

(중간분) 먼저 편하게.. 여기까지 온 소감을 말해 보세요

 
본격 질문시작...

(왼쪽분)

 - 빅데이터 분석에서 선형성과 등가성에 대한 설명

 - 기계학습에서 강화학습과 세미 슈퍼바이저의 차이점 

 - 포케스트와 프리딕트의 차이점

 - 스마트 팩토리를 IoT, 빅데이터 연계해서 설명해 보라

 - 하둡 2.0이 나온 배경, 1.0의 어떤 부분이 문제였나?

 

(중간분)

 - 위험과 이슈

 - DDoS를 xxx, xxx 관점으로 설명

 - VR에서 3D표현을 위해 중요한 기술

 - 게임이 산업으로 인정 받으려 한다. 견해는?

 

(오른쪽분)

 - UX설명과 UX설계시 페르소나.. 과정 설명

 - 게임피케이션 설명과 사례

 - 게임시나리오 어떤 과정으로 작성하나?

 - 오픈소스 많이 적용할텐데, 가장 고려해야 할 사항은?

 - 프레임워크와 플랫폼의 차이

면접 질문으로 비추어 보아, 왼쪽분은 확실히 빅데이터 전공하시는 교수님 같았다. 학자 스타일이 물씬 풍기는...

그리고 내 경력이 대체로 게임분야이다 보니, 게임 관련된 기술이나 이슈, 트랜드에 대한 질문이 많았던 것 같다.

당시 면접관이셨던 3분께..
좋은 점수 주셔서 이자리를 빌어 감사 드립니다 ^.^

요즘 개인정보가 핫(hot)? 하다.

산업 전 분야에 걸쳐 개인정보가 주요한 비즈니스 데이터로 활용되고 4차 산업혁명의 인공지능, 빅데이터, 사물인터넷 등의 융/복합 기술 기반에는 방대하고 광범위한 데이터가 활용되는데 여기서 개인정보 역시 예외가 아니다.

하지만 무분별한 개인정보의 활용은 많은 부작용을 낳는 것도 사실이다.

기업이나 개인은 타인의 개인정보를 활용할 때, 자칫 잘 못 하면 법 방망이(?)에 후드려 맞을 수 있다는 것을 명심해야 한다.

보통 개인정보를 정보시스템에 저장 또는 송/수신할 때 암호화 해야 한다고 알고 있는데, 그 기준이 모호할 때가 많다.

"모든 개인정보를 암호화 해야 하는가? 개인정보의 범위는 어디까지 인가?"

이 글에서는, 법령과 행정규칙에 근거하여 개인정보의 개념을 이해하고 암호화 대상과 방법에 대해 알아보고자 한다.

By 개인정보보호법

'개인정보보호법'에서는 '개인정보'를 다음과 같이 정의하고 있다.

[개인정보보호법, 제2조(정의)]

"개인정보"란 살아 있는 개인에 관한 정보로서 다음 각 목의 어느 하나에 해당하는 정보를 말한다

• 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보
• 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보. 이 경우 쉽게 결합할 수 있는지 여부는 다른 정보의 입수 가능성 등 개인을 알아보는 데 소요되는 시간, 비용, 기술 등을 합리적으로 고려해야 한다.
• 가명처리함으로써 원래의 상태로 복원하기 위한 추가 정보의 사용,결합 없이는 특정 개인을 알아볼 수 없는 정보(가명정보)

(참고) 가명처리
- 개인정보의 일부를 삭제하거나 일부 또는 전부를 대체하는 등의 방법으로 추가 정봅가 없이는 특정 개인을 알아볼 수 없도록 처리하는 것

법령 정의에 근거하여 개인정보를 해석하더라도, 개인정보의 범위는 매우 광범위 할 수 있으며 상황에 따라 해석이 달라질 수 있는 것을 알 수 있다

개인정보보호법의 '개인정보의 안전성 확보조치 기준'에서는 개인정보 암호화 대상 및 방법을 명시하고 있다.

[개인정보의 안정성 확보조치 기준, 제7조(개인정보의 암호화)]

• 고유식별정보/비밀번호/바이오정보를 정보통신망으로 송신하거나 보조저장매체 등을 통하여 전달하는 경우
• 비밀번호/바이오정보를 저장하는 경우(단 비밀번호를 저장하는 경우 복호화 되지 않도록 일방향 암호화 저장)
• 인터넷 구간 및 DMZ에 고유식별정보를 저장하는 경우
• 내부망에 고유식별정보를 저장하는 경우 다음 각 호의 기준에 따라 암호화 적용여부/범위 정하여 시행
  
  • 개인정보 영향평가의 대상이 되는 공공기관의 경우 해당 개인정보 영향평가 결과
  • 암호화 미적용시 위험도 분석에 따른 결과
• 개인정보를 암호화 하는 경우 안전한 암호알고리즘으로 암호화 저장
• 암호화된 개인정보를 안전하게 보관하기 위해 안전한 암호 키 생성, 이용, 보관, 배포 및 파기 등에 관한 절차 수립/시행
• 업무용 컴퓨터 또는 모바일 기기에 고유식별정보를 저장하여 관리하는 경우 상용 암호화 SW 또는 안전한 암호화 알고리즘을 사용

(고유식별정보)
- 주민등록번호 / 외국인등록번호 / 운전면허번호 / 여권번호

(암호화 미적용시 위험도 분석에 따른 결과)
- 개인정보처리시스템의 보호수준을 진단하여 암호화에 상응하는 조치를 했는지를 분석
- (참고) 개인정보 위험도 분석 기준 및 해설서

글로 나열된 법 조문으로는 한눈에 들어오지 않는다. KISA(한국인터넷진흥원)에서 발간한 '개인정보의 암호화 조치 안내서'의 요약표를 옮겨 보았다.

또한 해당 안내서에서는 안전한 암호 알고리즘을 안내하고 있다.

• 안전한 암호 알고리즘이란 국내 및 미국, 일본, 유럽 등의 국외 암호 연구 관련 기관에서 권고하는 암호 알고리즘을 의미
• 공공기관은 국가정보원의 검증대상 암호 알고리즘을 기반으로, 민간부문(법인,단체,개인)은 국내/외 전문기관(KISA, NIST, ECRYPT, CRYPTREC 등)이 권고하는 암호 알고리즘을 기반으로 개인정보보호법상의 개인정보 암호화에 사용할 수 있는 안전한 암호 알고리즘의 예시는 다음의 표와 같다.

By 정보통신망법

개인정보보호법 뿐만 아니라, 정보통신망법에서도 '개인정보의 기술적/관리적 보호조치 기준'을 통해 개인정보 암호화에 대한 행정 규칙을 명시하고 있다.

[개인정보의 기술적/관리적 보호조치 기준, 제6조(개인정보의 암호화)]

• 비빌번호는 복호화 되지 않도록 일방향 암호화해서 저장
• 다음 각 호의 정보를 안전한 암호알고리즘으로 암호화해서 저장
  • 주민등록번호
  • 여권번호
  • 운전면허번호
  • 외국인등록번호
  • 신용카드번호
  • 계좌번호
  • 바이오정보
• 개인정보 및 인증정보를 송/수신할 때에는 안전한 보안서버 구축 등의 조치. 보안서버는 다음 각 중 하나의 기능을 갖추어야 함
  • 웹서버에 SSL 인증서를 설치하여 전송 정보 암호화 송/수신 기능
  • 웹서버에 암호화 응용프로그램을 설치하여 전송 정보 암호화 송/수신 기능
• 개인정보를 컴퓨터, 모바일 기기 및 보조저장매체 등에 저장할 때에는 암호화
•  

개인정보보호법과 거의 유사하지만, 암호화 대상에 있어 두 가지(신용카드번호, 계좌번호)가 추가되어 있는 것을 확인할 수 있다.

결론

지금까지 관련 법령(개보법/정통망법)과 행정규칙을 살펴 보았는데, 쉽게 풀어서 결론 지으면 다음과 같다.

1. 고유식별정보(주민등록번호/운전면허번호/여권번호/외국인등록번호)와 비밀번호, 바이오정보는 무조건 암호화
(내부망 저장시 예외가 있긴 하나, 이는 한정된 기관(일부 공공기관 등)에 한하므로 패스. 상세한 내용은 위의 표 참조)

2. 암호화 할 때는 안전한 암호화 알고리즘을 사용
(안전한 알고리즘은 위에 표 참조)

3. 비밀번호는 (복회화 되지 않도록) 일방향 (해쉬) 암호화

4. 정통망법 적용 사업자는 추가로 신용카드번호, 계좌번호도 암호화

(주의)
이 글에서는 두개의 법(개보법/정통망법)만을 참조하여 작성되었습니다.
분야별로 법 적용이 다를 수 있으므로 사업자별로 적용받는 법(신용정보법, 위치정보법 등)을 추가로 확인해야 할 수도 있습니다.

(참고) FAQ

KISA가 발간한 '개인정보 암호화 조치 안내서'에는 실무자들이 암호화 조치 관련하여 자주 궁금해 하는 점들을 부록의 FAQ로 안내하고 있는데, 여기에 그 내용을 옮겨와 본다.

[Q1] . 개인정보 보호법 상의 암호화 대상은 무엇이며 어떻게 암호화해야 하나요?

개인정보 보호법상 암호화 대상은 고유식별정보(주민등록번호, 외국인등록번호, 운전면허번호, 여권번호), 비밀번호, 바이오정보입니다. 암호화 대상 정보를 전송시 그리고 저장시 아래 표에 따라 암호화하여야 합니다

[Q2]. 공공기관입니다. 개인정보처리시스템의 DBMS (DataBase Management System)에서 제공하는 TDE(Transparent Data Encryption) 방식을 사용한 암호화가 개인정보 보호법에 위배됩니까?

개인정보 보호법 관점에서는 개인정보의 안전성 확보조치 기준(고시)에 따라 고유식별정보 암호화시 안전한 알고리즘을 사용하도록 하고 있습니다. TDE 방식에서 안전한 알고리즘을 사용하여 암호화한다면 법 위반 사항이 아닙니다. 다만, 공공기관은 전자정부법에 따라 국가정보원이 안전성을 확인한 암호모듈 또는 제품을 우선 적용하여야 하며 자세한 사항은 해당 기관에 적용되는 관련 법령, 고시, 규정, 지침 등을 확인하시기 바랍니다

[Q3]. 암호화 관련하여 우리 기관(공공, 민간)에 적용되는 규정·지침과 개인정보보호법에서 적용하는 암호화 요구사항이 서로 다를 때 어느 것을 적용해야 하나요?

개인정보 보호법 및 시행령, 고시에서 규정한 암호화 요구사항을 준수하면 개인정보 보호법상 암호화 의무는 준수한 것입니다. 본 고시 준수로 인하여 다른 규정·지침을 준수하기 어렵게 된다면 “개인정보 보호법”은 준수 하였으나 해당 규정·지침은 위배한 것이 될 수 있습니다. 따라서, 최선의 방법은 개인정보 보호법과 해당 기관에 적용되는 규정·지침에서 요구하는 암호화 관련 사항 모두를 준수하는 것이라 할 수 있습니다.

[Q4]. 안전한 암호 알고리즘에는 어떤 것들이 있나요?

안전한 암호 알고리즘은 국내·외 전문기관에서 권고하고 있는 알고리즘으로서 본 안내서의 ‘[참고 1] 국내·외 암호 연구 관련 기관의 권고 암호 알고리즘’, ‘[참고 2] 국가정보원 검증대상 암호 알고리즘 목록’의 내용을 참고하시기 바랍니다

[Q5]. 대칭키 암호 알고리즘 DES나 해쉬함수 MD5를 사용하면 안 됩니까?

DES와 MD5와 같은 암호 알고리즘의 경우 안전성 유지가 어려우므로 안전한 암호 알고리즘으로 볼 수 없어 권고하고 있지 않습니다. 안전한 암호 알고리즘은 본 안내서의 ‘[참고 1] 국내·외 암호 연구 관련 기관의 권고 암호 알고리즘’, ‘[참고 2] 국가정보원 검증대상 암호 알고리즘 목록’ 내용을 참고하시기 바랍니다.

[Q6]. DB에 저장된 주민등록번호를 일부분만 암호화해서 저장해도 되는 것인지요?

예, 일부분 암호화가 가능합니다. 시스템 운영이나 개인 식별을 위해 해당 정보를 활용해야 하는 경우 생년월일 및 성별을 포함한 앞 7자리를 제외하고 뒷자리 6개 번호를 암호화 하여 사용할 수도 있습니다.

[Q7]. 암호화해야 하는 바이오정보의 대상은 어디까지 인지요?

암호화하여야 하는 바이오정보는 식별 및 인증 등의 업무절차상 수집이 명확한 경우로 한정되며, 이와 무관하게 수집되는 이미지, 녹취 정보 등은 암호화 대상에서 제외됩니다. 예를 들어, 콜센터 등에서 업무절차상 주민등록번호 수집이 명확한 경우의 음성기록은 암호화 해야 하나, 단순 상담 시 저장되는 음성기록 등은 암호화 대상에서 제외될 수 있습니다.

[Q8]. 안전한 대칭키 암호화 알고리즘 사용시 암호키(비밀키)의 길이는 어떻게 설정해야 하나요?

암호키의 길이가 짧거나 사용되는 문자의 종류를 섞어 쓰지 않으면 암호화가 되었더라도 공격자가 쉽게 암호 해독을 할 수 있습니다. 암호해독이 어렵도록 암호키 설정시 문자, 숫자, 특수문자 등의 문자조합 방법과 문자열 길이, 사용기간 등의 암호키 작성 규칙을 정하여 운영하는 것이 바람직합니다. 특히 잘 알려진 영문자, 숫자(1234, 123456, love, happy, admin, admin1234) 등은 쉽게 유추 할 수 있으므로 사용하지 않도록 주의해야 합니다.

[Q9]. 회사에 고객들의 이름, 주소, 전화번호, 이메일, 비밀번호를 저장하고 있습니다. 암호화 대상이 무엇인가요?

개인정보의 안전성 확보조치 기준 고시에서 암호화 대상은 고유식별정보(주민등록번호, 여권번호, 운전면허 번호, 외국인등록번호), 비밀번호, 바이오정보입니다. 특히, 비밀번호의 경우에는 일방향(해쉬) 암호화하여 저장하시면 됩니다

[Q10]. 부동산중개업을 하고 있습니다. 업무용 컴퓨터에 한글, 엑셀을 이용하여 주민등록번호를 처리 하고 있습니다. 암호화를 어떻게 해야 합니까?

PC에 저장된 개인정보의 경우 상용프로그램(한글, 엑셀 등)에서 제공하는 비밀번호 설정기능을 사용하여 암호화를 적용하거나, 안전한 암호화 알고리즘을 이용하는 소프트웨어를 사용하여 암호화할 수 있습니다.
※ 한컴 오피스 : 파일 >> 다른이름으로 저장하기 >> 문서 암호 설정에서 암호 설정 가능 ※ MS 오피스 : 파일 >> 다른이름으로 저장하기 >> 도구 >> 일반옵션에서 암호 설정 가능

[Q11]. A사가 개인정보처리시스템을 위탁하거나, ASP(Application Service Provider), 클라우드 서비스를 이용하는 경우 암호화 수행을 누가 해야 하나요?

개인정보의 암호화 등 안전성 확보조치는 원칙적으로 “개인정보처리자”의 의무입니다. 따라서 개인정보 처리시스템을 위탁하거나 ASP를 이용하는 경우에도 암호화 조치사항에 대한 이행여부에 대한 책임은 위탁기관인 A사가 지게 됩니다. 다만, A사는 암호화에 대한 요구사항을 A사의 위탁을 받은 수탁기관(ASP, 클라우드 서비스 제공자 등)과의 계약서 등에 명시하여 수탁기관으로 하여금 암호화를 처리하게 요구할 수 있습니다.

나에게 자격증은 일종의 도전이자 동기부여의 한 수단 이었다.

그리고 내 직무/전문분야에 대한 정리이자 증명의 수단이기도 했다.

그래서 나는 (운전면허를 제외하고는) IT 분야 자격증만 취득해 왔다. 

그간 취득한 자격증과 인증을 (취득 날짜 순으로) 정리해 보기로 한다.

인터넷 정보검색사 2급

(발행기관) 한국정보통신진흥협회

(취득일) 2001년 ?월 (몇 월 이었는지 기억도 안남)

군대를 제대하고 복학을 하니, 인터넷이란 것이 유행(?) 했더랬다. 당시 수업도 인터넷과 관련된 새로운 과목도 개강을 하여 들었던 기억이 난다.

사실 이 자격증은, (바로 아래에 있는) 전자상거래관리자 자격증을 준비하면서 재미로(?) 시험을 본 자격증이다.

(꽤 넓은 범위를 다루고 있는) 전자상거래관리사 자격증 공부 영역 중 일부에 해당하기도 했었고, 시험 자체가 집에서 컴퓨터로 온라인 시험을 보고, 결과도 그 자리에서 바로 나와서 아주 쉽게 취득한 자격증이다. 물론 그만큼 가치도 별로 없다.

이 자격증은 내 이력서에서도 제외하곤 하지만, 그래도 내 첫 IT 분야 자격증이니 여기에 기록해 본다.

전자상거래관리자 2급

(발행기관) 대한상공회의소

(취득일) 2001년 7월

대학 졸업반 시절, IT 관련 일을 준비하면서 취득하게 된 자격증이다.
당시 이 자격증의 광고와 홍보가 많이 이루어졌고, 뭔가 그럴싸해 보였다.(돌이켜 보니 광고에 혹했고 내가 순진했다.)

당시 정보처리기사급 정도 되었던 것 같다. (당시 지인이 옆에서 정보처리기사를 공부했더랬다)

1차 필기/2차 실기 시험 이었는데, 1차 필기는 다루는 범위가 꽤나 방대했었고
2차 필기는 직접 컴퓨터를 가지고 각종 작업(IIS 웹서버 셋팅/ASP 등)을 해야 해서 나름 공부 많이 하고 취득한 자격증이다.

OCP(Oracle Certified Professional) 9i

(발행기관) Oracle

(취득일) 2004년 3월

오라클이라는 외국의 유명한 DBMS 회사에서 주최하는 자격 시험이다.

실무에서 DB를 다루기도 하고, 뭔가 있어 보이기도 하고, 학원에 자격반 커리큘럼도 있고 해서 준비하게 되었다.

필기 시험으로만 취득하는 페이퍼 자격증이라는 오명을 벗기 위해, 9i 버전 부터는 일정 시간 이상 실무 교육을 필수로 요구했었다.

그래서 꽤 비싼 수강료를 지불하고 실무 강의도 수강했었다. 매일 저녁 멀리 있는 학원에 가는게 매우 귀찮았던 걸로 기억한다.

MCAD (Microsoft Certified Application Developer)

(발행기관) Microsoft

(취득일) 2005년 1월

부산의 동명정보기술원이라는 기관에서 같이 공부하던 여러 사람들과 같이 준비하고 취득한 자격증이다.

마이크로소프트에서 주최하는 국제 자격증으로 MS 기반 개발자를 위한 자격 인증 시험이다.

당시에는 MCAD, MCSD, MCT 로 이어지는 도전을 생각했으나, 이 자격증 까지만으로 만족(?)해 버렸다.

MS MVP(Microsoft Most Valuable Professional), C# 부문

(발행기관) Microsoft

(취득일) 2008년 7월

이건 자격증이 아니라 인증 프로그램이다. 마이크로소프트에서 자사의 각 기술 분야에 대한 전문가를 인증하는 프로그램으로 별도의 자격 시험을 치루는 게 아니라, 전문가 활동을 한 내역 증명과 심사 통과가 필요하다.

전문가 활동이란, 해당 기술 분야에 대한 책을 쓰기나 강의를 하거나 기술 블로그 등에 글을 작성 하거나 Q&A에 답변을 하는 등 그 활동으로 인해 '해당 기술을 널리(?) 알리고 타인을 (기술적으로) 도와 주었는가?'를 심사한다.

자신의 전문가 활동 내역을 정리해서 영문으로 (제공되는) 포맷에 맞게 제출하면 심사가 이뤄지는데,
'한국 -> 아시아 -> MS 본사' 순으로 심사가 진행되는 것으로 기억한다.

MS 제품과 관련한 다양한 분야의 MVP를 선발하는데, 나는 당시 실무에 주력 언어로 사용하던 C# 부분에 지원 했었다

처음 시도 했을 때, 한번 미끄러지고 두 번째 시도에 통과했었다.

당시 MS MVP는 공신력도 있었고, MS 계열 엔지니어들에게서 꽤 선망의 대상이어서 심사에 통과하고 많이 뿌듯했었다.

PMP(Project Management Professional)

(발행기관) PMI

(취득일) 2009년 6월

2008년부터 팀장 직무를 수행하게 되었는데, 이 때 프로젝트 관리에 관심을 가지게 되었고 이왕 하는거 제대로 해 보자는 마음으로 준비하게 된 자격증이다.

국제적 프로젝트 관리 기관인 PMI(Project Management Institute)에서 프로젝트 관리 전문가에게 부여하는 자격증이다.

이 자격증을 위해 라이지움이라는 학원도 다녔었다. 공부할 내용이 방대하고 복잡한 계산 문제도 있어서 정성을 꽤나 쏟았다.

시험 보는 날이 아직 머리속에 생생하다. 시험은 정해진 시험 장소에 가서 컴퓨터로 치룬다. 시험 결과는 시험 종료 후 최종 제출을 하면 몇 분 기다리다가 바로 나온다. 그 몇 분의 떨림이란...

첫번 째로 응시한 시험에 (운 좋게) 합격하여, 기분 좋게 복귀 했던게 생각난다.

기술사(정보관리)

(발행기관) 한국산업인력공단

(취득일) 2016년 5월

이건 매우 비장한 각오로 준비한 자격증이다. 혹독한 준비 과정을 각오했으며 주말도 반납하며 공부 했었다.

1차 논술 시험과 2차 면접 시험으로 구성되어 있다.

1차 시험은 1교시 90분씩 총 4교시 시험을 치르게 되는데, 시험 시간만 자그마치 6시간이다.
이 6시간을 혼신의 힘을 다해 논술해 나가야 한다. 오전 9시에 시작해 오후 6시 조금 전에 시험을 마치는데 시험을 치고 나면 녹초가 되는 기분이었다.

2차 시험은 대학교수/기술사로 구성된 3명의 면접관 앞에서 (외로이?) 질문에 성실히 답해야 한다. 기술적인 답변을 잘 하는 것이 제일 중요하나, 구술시험이다 보니 임기응변과 순발력과 재치도 필요하다.

이 자격증은 1차 시험 합격이 중요한 시험이다. 2차에 비해 1차의 합격률이 매우 낮으며 2차 시험은 1차 합격 이후 4번 정도의 기회가 부여 되기 때문에, 1차 합격하면 기술사가 된 것으로 인정하는 분위기이다. (물론 2차에 고배를 여러차례 마신 분들도 있긴 하다)

나의 경우, 1차 시험 합격 기준으로 총 1년 6개월 정도 걸렸으며 (6개월 마다 있는 시험 일정에) 총 3번의 시험을 치뤘다.

첫번째 시험은 공부 시작한지 얼마 안되서, (기대도 없이) 경험삼아 보게 되었고, 두 번째 시험은 작심하고 봤다.

두 번째 시험에서 살짝 아깝게 떨어지고, 세 번째 시험에 (운좋게) 합격하게 되었다. 면접도 한번에 붙어서 매우 기뻤다.

매우 힘든 과정과 시험이었지만, 뭔가를 (오랜 기간) 제대로 준비하고 모든 것을 쏟아 부어 성취한 느낌을 주게 한 소중한 자격증이다.

2017/12/22 - [자격증] - [기술사] 철지난 합격수기

2016/10/09 - [자격증] - KPC 공개설명회

정보시스템 수석감리원

(발행기관) 정보시스템감리협회

(취득일) 2016년 7월

기술사 자격을 취득하면 (별도의 시험이나 감리 경험 없이) 5일간의 감리교육만 이수하면 수석감리원 자격이 부여된다. 기술자 자격의 혜택 중 하나이다.

실제 감리를 수행하는 과정이 교육 커리큘럼이라 5일간 꽤 낯설고 힘들었던 기억이 난다.

교육 마지막날 소정(?)의 필기 시험이 있는데 교육을 충실히 듣고, 공부 조금 했다면 그리 어렵지 않게 통과할 수 있다. 물론 그 전에 기술사 공부로 어느정도 감이 있어서 도움이 되었다.

데이터 품질인증(DQC-V) 심사원

(발행기관) 한국데이터진흥원

(취득일) 2016년 8월

한국데이터진흥원에서 주최하는 데이터 관련 3종 인증 심사원 중 데이터 품질에 관한 심사원 자격이다.

3일간(2일인가? 기억이 가물)의 교육, 주말 시험으로 취득할 수 있다.

교육은 참신하고 재미있었는데... 이 시험이.. 만만하게 볼 게 아니다.

아무래도 실무 현장에 가서 의뢰 기관의 데이터 품질을 객관적으로 측정하는 일을 해야 되다 보니, 시험에 신경을 꽤 쓴 느낌이었다.

중요한 것은, 다른 심사원 자격보다 보수가 짭짤한 것이 장점이다ㅏ.

2016/09/29 - [자격증] - 데이터 품질(DQC-V) 인증심사원

ISMS-P (정보보호 및 개인정보보호 관리체계 인증)

(발행기관) KISA

(취득일) ISMS: 2016년 10월 / ISMS-P: 2019년 5월

기업(기관)의 정보보호관리체계/개인정보보호관리체계를 점검하고 심사하는 인증 심사원을 양성하기 위한 자격 시험이다.

2016년에 필기 시험 치고, 5일간 실무 교육 받고 ISMS 심사원 자격을 취득했다.

이후 ISMS와 PIMS가 ISMS-P로 통합 되면서 이틀간 전환 교육 받고 필기시험 한번 떨어지고,
재시험에 통과하여 최종적으로 ISMS-P 심사원 자격을 취득했다. 

필기 시험이 쉽지 않다.

과거에는 교육만 받으면 자격이 나왔다고 하는데, 심사원의 전문성과 자질 문제가 불거지면서 필기 시험이 도입되었다.
그 필기가 도입되고 얼마 안되 2016년에 내가 시험을 보게 된 것이다.

문제 수도 많고, 각 문제 지문도 길고, 다지 선다(압권은 모두 고르시오)에.. 

2016년 당시 시험 시간이 턱없이 부족했었던 기억이 난다. 정말 꾸역꾸역 시험을 쳤는데 진짜 운 좋게 합격한 것 같다.

2019년에 ISMS-P 시험은 2016년 당시 시험 보다는 여유롭게 봤지만 쉽지는 않았다.

2016/10/29 - [자격증] - ISMS 인증심사원 자격취득

소프트웨어 보안약점 진단원

(발행기관) KISA

(취득일) 2017년 11월

말 그대로 소프트웨어의 보안 약점을 진단하는 심사원 양성을 위한 자격증이다.

5일간의 교육과 마지막날 필기 시험을 치러야 한다.

필기 시험이 꽤 어렵다.

(ISMS-P도 그렇고) KISA는 시험 난해하게 내기로 작정한 모양이다. ㅋ

물론 심사원 취득 과정이 험난(?)해야 제대로 된 심사를 하니깐 난해함을 존중하는 바이다.

이상..

그간 취득한 자격증을 정리해 봤다.

치열했던 나의 도전에 박수를 보낸다 !!!

늘 같은 일상이 반복되면서,

나에게 주어진 소중한 것들을 너무나도 당연시 여기며 살고 있다는 것을 ...

심지어 여기에서 진화하여,

사소한 불편에 집중하고 중대한 불만으로 승화(?) 시키고 있다는 것을 ...

일상의 출근길 가운데 불현듯 뇌리를 스쳐 지나갔다.

감사하며 살아야 겠다고 다시 다짐해 본다.

감사하며 살되, 나태해 지지는 말자라고...

아마... 아래 그림은 한번쯤은 본 적이 있을 겁니다.
개개인의 서로 다른 재능을 무시한채, 획일적인 기준으로 평가하는 문제를 풍자하는 그림인데요..

이 카툰은 획일적인 교육과 평가에만 의존하는 교육분야의 문제 인식으로 자주 인용되지만, 기업의 경영 전략에도 대입해 볼 수 있다는 생각이 듭니다.

기업의 존재 목적은 수익 창출입니다. 모든 기업은 수익을 창출하기 위해 다른 기업과는 차별화된 재화나 서비스를 시장에 공급합니다. 이러한 수익 창출 과정에서 주어진 자원을 최대한 효율적으로 사용해서 수익을 극대화 시키고 리스크(risk)를 경감하는 것이 중요합니다.

따라서 기업은 자신이 제공하는 핵심 서비스 전개를 위한 업무 역량은 자체적으로 내재화 시켜서 경쟁력을 확보하고 다른 기업과의 차별화를 꾀해야 합니다. 

반면, 핵심 서비스에 직접적이지 않은 비 핵심업무는 다른 기업이나 다른 사람에게 위임하여 그들의 전문성을 활용하는 것이 좋습니다. 그렇게 해야 생산성이 향상하고 리스크를 경감할 수 있습니다. 

기업의 외주(아웃소싱) 전략에 좋은 참조 모델이 있어 소개하고자 합니다.

---

'캐즘(Chasm) 이론'으로 유명한 제프리 A.무어의 '코어/컨텍스트(Core/Context) 모델'은 기업이 주어진 자원을 어떻게 운용하는 것이 좋을지에 대한 참조 모델을 제시하며 '클라우드 충격'이라는 책에서 자세히 설명하고 있습니다.

코어(Core)란 의미 그대로 기업의 핵심 업무를 말합니다. 코어 업무는 기업의 경쟁우위를 높여주는 중요한 것이므로 최대한 자원을 집중해야 하고 자체 개발을 해야 한다는 것입니다.

반면 컨텍스트(Context)는 코어 이외의 모든 활동이라고 말합니다. 컨텍스트 업무는 차별성을 추구하는 것이 아니라 가능한 표준적인 방식으로 효율을 최우선으로 수행하는 것'이 좋다고 말합니다.

또한 이러한 컨텍스트 업무는 어느 누군가에게는 코어 업무이기 때문에 그쪽에 아웃소싱을 맡길 수 있다고 시사합니다.

게임을 개발하는 기업에서 인사관리 프로그램이 필요한 사례를 예로 들어 보겠습니다.
게임 개발은 회사의 중요한 코어 업무이기 때문에 자체 개발을 해야 하며, 인사관리 프로그램은 컨텍스트 업무이기에 그 업무를 코어로 하는 외부 업체에게 아웃소싱 하는 식입니다.

그러나 코어/컨텍스트만으로는 기업내 모든 활동을 양분하기에는 한계가 있어 보입니다.

무어는 코어/컨텍스트 구분과 더불어, '미션크리티컬/'비미션크리티컬' 이라는 또 하나의 축을 또 다른 기준으로 내세웠습니다. 미션 크리티컬은 만일 중지되었을 때 즉시 심각한 리스크로 이어지는 기업 활동을 말하며 그 외의 모든 업무는 비 미션크리티컬이 됩니다. 즉 리스크의 정도를 기준으로 삼고 있습니다.

이에 대한 도식은 아래와 같습니다.

[출처: 클라우드의 충격]

---

제가 속해 있는 IT 분야에서도 아웃소싱 전략에 큰 영향을 주는 두가조 요소가 있습니다.

바로 클라우드(Cloud)와 오픈소스(Opensource)입니다.

오픈소스의 경우 외주(아웃소싱)라는 카테고리와는 성격이 조금 다를 수 있지만, 특정한 업무를 외부 자원으로 해결한다는 위임이라는 측면에서는 맥을 같이 하기에 연결지어 봤습니다.

클라우드의 경우 종전의 자체 전산실에 직접 렉과 장비를 구비하고 운영했던 온프레미스(On-Premise) 환경과는 달리 클라우드 환경에서는 이러한 물리적인 장비와 운영체제, 소프트웨어까지 빌려 쓸 수 있게 되었습니다. 또한 기업은 자신들이 어디 까지를 직접 운영할지 결정하여 Iaas, Paas, Saas 형태의 클라우드 서비스 모델을 선택할 수 있습니다. 

갈수록 IT 환경의 판이 많이 달라지고 있습니다. 자원을 최적화 시키는 것은 기업의 생산성을 향상시키는 것 뿐만 아니라, 서로 다른 재능을 가진 기업간 위임이 활성화 되어 산업의 발전에도 기여하게 된다고 봅니다. 과거 분업화가 많은 발전을 야기한 것 처럼요.

현재 자신의 회사나 수행하는 프로젝트에서, 코어와 컨텍스트, 미션크리티컬과 비미션크리티컬의 4사분면에 해당하는 업무가 무엇인지 파악하여 전략을 재정비 해 보는 것도 좋을 것입니다.

지금까지 IT업계에 20년 가까이 일을 하면서, 많은 팀을 겪어 왔습니다.
역할로는 팀원에서부터 파트장, 팀장까지 다양하게 경험을 해왔으며 현재도 진행중이지요.

팀과 프로젝트를 리딩한 경험도 다양한데, 팀의 규모로는 3명에서부터 20명이 넘는 팀을 리딩해 본 경험이 있습니다.

또한 경험해 온 조직 환경도 무지 다양한데, 여러 회사의 다양한 팀 구조와 문화를 체험했습니다.
 
인터넷 컨텐츠 회사에서 부터, 게임회사, 대기업 SI 등의 서로 다른 조직 문화에서 팀 작업을 수행해 왔으며, 팀의 조직화 특성으로는 보통의 기능조직 성격의 팀에서부터 프로젝트에 특화된 TFT(Task Force Team) 형태의 팀구조를 겪어 봤습니다.

지금까지 제가 경험해 온 팀들은 제각각 다른 특성이 있었지만, 결국 사람이 모여서 일을 하는 것이라는 점에서 팀의 근원적 특성은 크게 다르지 않았습니다. 즉 팀이 결성되고 협업하고 때론 갈등에 직면하고 목표를 달성해 나가는 근본적인 원칙과 과정은 크게 다르지 않았다고 생각합니다.

오래전 팀리딩을 시작하게 되면서, 프로젝트 관리와 동기부여에 관련된 다양한 이론과 지식을 찾아서 학습해 왔습니다. 그전(팀원일때)에는 관심 없었던 다양한 경영이론과, 심리학 이론 등이 존재하더군요.

이 글에서는 그 중 하나인, Tuckmana의 팀 발달 모델을 소개하고 제 개인의 경험과 접목하여 글을 정리해 볼까 합니다.

Tuckman's Team Development Model

1965년, 심리학 교수인 Bruce Tuckman은 'Developmental Sequence in Small Groups'이라는 논문을 통해 Team Development Model이라는 경영이론을 발표했습니다.

팀이 형성되고 발달해 나가는 과정을 4단계로 나눈 이 모델은, 각 단계별로 팀이 겪게 되는 특징을 잘 설명합니다. 첫 논문 발표시 4단계였던 것이 1977년에 Adjourning 단계가 추가되면서 현재는 총 5단계 모델로 알려져 있습니다.

국제적인 프로젝트관리 협회인 PMI에서 발행하는 PMBOK에서도 '인적자원관리'라는 챕터에 '프로젝트 팀 개발' 이라는 지식영역에서 이 모델을 팀 관리의 참조 모델로 안내하고 있습니다.

팀 리더는 팀 운영과 프로젝트의 성공을 위해 이 모델을 활용할 수 있습니다. 팀이 발달하는 과정을 이해하고 각 단계별로 당면하는 팀의 상황과 각 상황별로 필요한 리더십 스타일을 이 모델의 이론에 근거하여 결정할 수 있습니다.

개인적으로도 이 모델은, 그간 제가 맡아온 팀을 이해하고 문제를 해결하고 리딩 스타일을 결정하는데 많은 도움이 되었습니다.

Tuckman에 의하면 팀은 (아래 도식에서와 같이)  5단계의 과정을 거치게 됩니다. 처음에 혼돈과 불확실성으로 가득찬 상태에서 긴장과 대립, 갈등이 촉발되는 시기가 옵니다. 이후 각 시행착오를 거치면서 팀은 성장하고 프로젝트를 성공적으로 완수할 수 있게 됩니다. 물론 잘 운영되는 경우에 말이지요.

출처: https://www.lfhe.ac.uk/download.cfm/docid/3C6230CF-61E8-4C5E-9A0C1C81DCDEDCA2

Tuckman의 이론을 하나의 표로 요약해 봅니다.

처음 이 모델을 봤을 때, 참으로 공감되는 내용이 많았습니다.

제가 맡은 여러 형태의 팀들 중에서도 특히, 프로젝트에 특화된 팀(TFT)이나 SI 프로젝트를 수행하는 팀 구조에서 이 모델의 적합성이 더 높았습니다.

각 단계별 리더십 스타일

이 글에서 하고자 하는 얘기의 핵심입니다. 팀리더가 어떻게 해야 팀을 원만하게 운영하고 프로젝트를 성공시키느냐 하는 것입니다.

팀리더는 프로젝트를 성공시키고 팀을 성장시키는데 책임이 있습니다. 그 책임을 다하기 위해서는 팀과 팀 구성원들을 정확히 이해하고 자신의 리더십 스타일을 적절히 변경할 수 있어야 합니다.

즉 팀 리더는 Tuckman의 모델에 참조하여 팀을 이해하고 자신의 리더십 스타일을 결정하거나 조정할 수 있습니다.

여기에 좋은 안내서가 있습니다.

https://kristalaace2014.wordpress.com/2014/02/26/w1_al_tuckman-analysis-assignment/comment-page-1/

위의 표는 각 단계별로 팀리더의 스타일을 안내하고 있습니다. 저도 이 표를 보면서 간과했던 부분을 다시금 깨닫는 계기가 되었습니다.

형성기(Forming)

모든것이 불명확하고 불확실한 상태입니다. 프로젝트의 목표와 과제에 대해 공감과 이해가 부족한 상태이며, 구성원들은 서로 어색하고 신뢰가 형성되지 않은 시기입니다.  

'우리가 여기에 왜 모였는가?'' 를 분명히 해야 합니다.

팀 리더는 팀 구성원들이 길을 잃지 않고 프로젝트를 수행할 수 있는 초석을 마련해야 합니다. 프로젝트의 목표와 방향성을 명확히 수립하고 전달해야 합니다. 또한 R&R을 설정하는 동시에 구성원 개개인과 프로젝트 과제(What) 자체에 집중해야 할 시기입니다.

다시 말하자면, 우리가 왜 모였으며 무엇을 언제까지 누가 어떤 일을 해야 하는지를 명확히 해야 할 시기입니다. 그러므로 이 시기에는 보다 직접적인 리더십 스타일이 필요한데 이를 지시형 리더십 스타일이라 하겠습니다.

격동기(Storming)

앞서 형성기의 단계를 거쳐, 팀 구성원들은 프로젝트의 목표와 개인의 역할을 인지하게 되었습니다. 이제 본격적으로 각 구성원들이 프로젝트를 위해 일을 시작하는 시기입니다. 그러나 이제 막 모인 사람들은 각자의 업무 스타일과 개성이 표출됩니다. 이로 인해 잦은 의견충돌과 대립이 발생하면서 긴장상태로 접어들기도 합니다. 말 그대로 격동기 입니다.

팀 리더로써 가장 중요한 시기입니다. 다름과 틀림을 구분할 수 있도록 해야 합니다. 구성원들의 서로 다른 업무 스타일로 갈등이 고조되지 않도록 하는 조치가 필요합니다. 팀이 일을 하는 방식에 대한 표준(기술표준, 프로세스 표준, 의사결정 방식 등)이 반드시 필요합니다. 각자의 스타일을 존중하되, 협업을 위한 표준으로 각자의 업무 스타일을 조화시켜야 합니다.

이 시기의 팀 리더는 구성원들의 개인적인 상호작용에 많은 관심을 가져야 합니다. 구성원들의 의견 불일치, 갈등을 적극적으로 중재해야 합니다. 이때 팀의 표준과 프로세스가 많은 도움이 됩니다.

코치형 리더십 스타일이 필요하다 하겠습니다. 특히 개인적인 관계를 촉진하는 역할이 중요합니다.

INTRO

일정 규모 이상의 정보 서비스를 제공하고 있다면, 아마도 대부분 한대 이상의 서버를 배치하여 부하분산을 시키고 있을 것입니다. 이런 배치 전략을 로드밸런싱이라고 하죠.

로드밸런싱은 대량의 트래픽을 수용하기 위해 여러대의 (동일한) 서버가 요청을 나눠서 처리하도록 하는 부하분산을 통해 서비스의 처리량을 증가 시키고자 하는 것이 주 목적입니다. 

물론 로드분배 알고리즘과 서버 상태를 기반으로 해서 고가용성(HA)의 요건도 같이 충족되는 것이 일반적입니다.

만일 트래픽이 점점 더 늘어난다면, 그에 맞춰 Service #4, Service #5, ... 이런식으로 서비스의 복제본을 늘려 나가기만 하면 되기 때문에 손쉽게 확장이 가능합니다.

애플리케이션의 확장성을 보장하기 위해서는 다양한 전략을 구사할 수 있습니다. 로드밸런싱은 그 중에서도 트래픽의 처리량을 증가시켜서 서비스의 능력을 향상하는 아키텍처 전략에 해당합니다.

이 글에서는 애플리케이션의 확장성 보장을 위한 다양한 전략을 'Scale Cube'라는  규모 확장성 모델에 근거하여 설명하고자 합니다.

확장성

먼저 소프트웨어 분야의 확장성이라는 개념을 먼저 정리하자. 확장성은 쉽게 말해서,

애플리케이션이 얼마나 손쉽게 확장될 수 있는 가에 대한 가능성에 대한 정도로써 애플리케이션의 여러 품질속성 중 하나이다.

확장성이 좋다는 말은, 애플리케이션의 능력을 손쉽게 향상 시킬수 있다는 의미가 된다.

여기서 애플리케이션의 능력이란, 알고리즘이나 로직과 같은 세부적인 기능 측면보다는 성능/가용성/보안과 같은 비기능적인 요소(이를 품질속성이라 함)에 해당하는 능력을 말한다.

'정보통신기술용어해설'에서는 확장성을 다음과 같이 정의하고 있다.

대규모적인 재설계/재설치 등의 필요없이 확장이 얼마나 쉽고 가능한가에 대한 용이성

확장의 대상과 확장 방식에 따라 확장성을 다음과 같이 세분화 할 수 있다.

1) 규모 확장성
일반적으로 모든 확장성은 규모 확장성을 의미한다. 규모란 용어는 양적인 측면의 크기를 지칭하는 용어로써 특정 대상만을 한정하지는 않는다. 예를 들어 트래픽 처리량에 대한 규모, 데이터 보관량에 대한 규모, 기능의 종류와 양에 대한 규모 등 얼마든지 수식이 가능하다.

다만, 여기서의 규모 확장성은 아래에 설명하는 다른 확장성과 구분하기 위해 트래픽 처리량에 대한 확장으로 한정하고자 한다.

규모 확장성을 보장하기 위해서는 앞서 살펴본 로드밸런싱과 같이, 동일한 기능을 수행하는 애플리케이션의 복사본을 여러대 구성하여 트래픽 부하를 나눠 가지도록 구성한다. 이런 구성을 Scale out(수평 스케일)이라고도 하며 손쉽게 트래픽 처리량을 확장할 수 있어 흔히 사용되는 방법이다.

규모 확장성을 보장하는 로드밸런싱의 구조를 다시 확인해 보자. Service #1~#3은 모두 동일한 복제본으로 동일한 기능을 수행한다.

2) 기능 확장성
애플리케이션의 기능을 얼마나 손쉽게 추가, 수정할 수 있느냐에 대한 정도이다. 다시 말해, 기존 기능을 확장하거나 새기능을 추가하여 애플리케이션의 능력을 향상시킬 수 있는 가능성에 대한 정도로 풀어 쓸 수 있다.

과거 유행했던 SOA(Service Oriented Architecture)와 근래 유행하는 MSA(Micro Service Architecture)가 바로 기능 확장성 보장하는 아키텍처 구조이다.

MSA는 애플리케이션을 기능 및 역할 관점에서 분리하여 개별 서비스로 구성하고 상호 연동을 통해서 전체 애플리케이션을 구성하는 방식으로 애플리케이션의 독립성과 자율성을 보장함으로써 유지보수와 기능 확장을 용이하게 하는 아키텍처 구조이다.

다음 그림은 애플리케이션이 역할 단위로 분리되어 서로 다른 기능을 제공하는 모습을 보여준다.

3) 데이터 확장성
각각의 애플리케이션이 데이터의 일부분만을 책임지도록 하여 처리 효율을 증가시키거나 데이터 규모에 대한 확장성을 확보하는 기법이다. 데이터 샤딩이나 파티셔닝같이 데이터 자체를 분리하여 저장하는 방식으로 많이 활용되며 경우에 따라서는 애플리케이션 단위의 파티셔닝을 통해 각각이 애플리케이션이 서로 다른 데이터 영역을 책임지게 함으로써 데이터의 처리효율과 애플리케이션의 처리 성능을 향상시킬 수 있다.

다음 그림은 서로 다른 데이터가 서로 다른 저장소에 분리되어 저장된 샤딩된 구조를 보여준다.
여기서 각 Application은 모두 동일한 복제본으로 동일한 기능을 실행하지만 책임지는 데이터 영역이 서로 다르다.

예를 들어, 대량의 데이터에 대한 검색 기능을 개발한다고 할 경우, 다음과 같이 검색 API를 두고 뒷단으로 애플리케이션을 파티셔닝해 그 결과를 조합해서 반환하도록 구성할 수도 있다.

The Scale Cube

'THE ART OF SCALABILITY'라는 책에서는 매우 유용한 3가지 차원의 규모 확장성 모델을 제시한다고, 'Chris Richardson'이 서술한 바 있다.

상단의 그림은 Chris Richardson의 The Scale Cube라는 글에서 발췌해온 것이다. Chris Richardson은 해당 글에서 각 축(axis)에 대해서 설명한다. 글이 짧지만 핵심을 잘 전달해 주고 있으니 일독해 보기를 권장한다.

어느 훌륭한 한국분이 이 글을 번역해서 올려 뒀으니 참고 바란다.
> 스케일 큐브 (크리스 리차드슨)

X축 확장
애플리케이션의 동일한 복제본을 다수로 구성하여 애플리케이션의 처리 능력을 향상시키는 기법이다.
앞서 살펴본 처리량에 대한 확장성 즉, '규모 확장성'이 바로 이 축에 해당한다.

Y축 확장
애플리케이션의 기능을 역할별로 분리하여 서로 독립적인 서비스로 구성하는 기법이다.
앞서 살펴본 '기능 확장성'이 바로 이 축에 해당한다.

Z축 확장
데이터이 일부만을 책임지도록 하여 데이터 저장과 활용 관점에서 애플리케이션의 처리 능력을 향상시키는 기법이다. 앞서 살펴본 '데이터 확장성'이 바로 이 축에 해당한다

확장성 모델 요약

각각의 확장성 모델을 다음과 같이 하나의 표로 정리해 보았다.

실무 환경

실제 실무환경에서는 각각의 확장성 축이 모두 혼합되어 구성되는 것이 일반적이다. 특히 MSA 아키텍처 구조를 표방하는 애플리케이션들은 거의 대부분 아래와 같은 구조로 설계된다. 즉 모든 축의 확장성을 보장하는 형태로 구성하여 극강의(?) 확장성을 확보한다.

[출처: 마이크로서비스 아키텍처로 개발하기(안재우)]

INTRO

근래 대부분의 해킹 사고는 개인정보 유출과 직결됩니다.

해커는 기업이 보유하고 있는 고객의 개인정보를 불법적으로 탈취하여 금품을 요구하거나 탈취한 개인정보를 또다른 불법적인 용도로 활용하게 됩니다.

따라서 기업의 해킹 사고는 (그들만의 문제가 아니라) 그 피해가 우리와 같은 일반 이용자게까지 미치게 되는 것입니다.

이에 현행 법제도에서는 기업이 제대로 관리/감독 하지 않아서 발생한 개인정보 유출 사고에 대해 과징금, 시정명령, 손해배상과 같은 행정처분을 부과할 수 있는 법적 근거를 마련해 두고 있습니다.

이번 글에서는 법에서 명시하고 있는 행정처분의 규정을 살펴보고, 그간 실제 발생한 해킹사고에서 기업에게 부과된 행정처분 사례를 알아 보겠습니다.

개인정보 보호 관련 법체계
개인정보보호와 관련된 가장 보편적인 법은 '개인정보보호법'이다.

개인정보보호법은 2011년 3월 29일 처음 제정/공포되어 6개월 뒤인 2011년 9월 30일에 첫 시행된 이후 지금까지 지속적인 법개정을 거듭하고 있다.

또한 정보통신망법(정보통신망 이용촉진 및 정보보호 등에 관한 법률)과 신용정보법(신용정보의 이용 및 보호에 관한 법률) 등에서도 개인정보 활용과 보호에 대한 법적 규정을 따로 마련해 두고 있다.

특별법 우선 원칙
법은 크게 일반법과 특별법으로 나뉜다.

특정한 대상(지역/사람/사항 등)에 제한없이 적용되는 법을 일반법이라 하고, 특정한 지역/사람/사항 등에 국한하여 적용되는 법을 특별법이라 한다.

예를들어, 모든 지역의 모든 사람에게 공통으로 적용되는 형법, 민법과 같은 법은 일반법에 해당하며, 특정 대상에 국한하여 적용되는 김영란법, 아동청소년법 등은 특별법에 해당한다.

특별법은 일반법에 우선하여 적용되는데 이를 '특별법 우선 원칙'이라 한다.

개인정보보호법 6조에서도 다음과 같이 법률간 관계를 규정하고 있다.

개인정보보호법 제6조(다른 법률과의 관계) (법조문 바로가기)

개인정보 보호에 관하여는 다른 법률에 특별한 규정이 있는 경우를 제외하고는 이 법에서 정하는 바에 따른다. 

다시 말해 일반법과 특별법에 중복된 규정이 존재할 경우, 특별법이 우선 적용되며 특별법에 존재하지 않는 규정에 대해서만 일반법이 적용되는 체계이다.

앞서 설명한 개인정보 보호 관련 법들도 이런 체계를 따른다.

개인정보보호법은 개인정보를 다루는 곳이라면 누구에게나 구분없이 적용되는 일반법이며, 정보통신사업자에게 적용되는 정보통신망법은 특별법에 해당한다.

[출처: 금융위원회(2016)]

상단의 그림과 같이 기업의 업종에 따라 법 적용이 구분된다. 따라서 해킹 사고로 인해 개인정보가 유출된 경우, 기업이 어떤 처벌을 받게 되는지 알고 싶을 경우에는 해당 기업이 어떤 법에 적용을 받는지 파악해야 한다.

이 글에서는 정보통신망법에 초점을 맞춰 알아 볼 것이다.

개인정보 유출에 대한 법적 규제(행정처분 근거 법령)
개인정보 유출로 이어지는 해킹 사고 발생시, 해당 기업을 규제할 수 있는 법적 근거에  대해 알아보자. 다음 그림은 개인정보보호법과 정보통신망법을 기준으로 적용 가능한 법적규제와 조문을 보여준다.

행정처분 중 과징금 부과에 대한 법규정을 살펴보면 다음과 같이 기술하고 있다.

개인정보보호법 제34조의 2(과징금의 부과 등) (법조문 바로가기)

① 행정안전부장관은 개인정보처리자가 처리하는 주민등록번호가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손된 경우에는 5억원 이하의 과징금을 부과ㆍ징수할 수 있다. 다만, 주민등록번호가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 개인정보처리자가 제24조제3항에 따른 안전성 확보에 필요한 조치를 다한 경우에는 그러하지 아니하다.

정보통신망법 제64조의3(과징금의 부과 등) (법조문 바로가기)

① 방송통신위원회는 다음 각 호의 어느 하나에 해당하는 행위가 있는 경우에는 해당 정보통신서비스 제공자등에게 위반행위와 관련한 매출액의 100분의 3 이하에 해당하는 금액을 과징금으로 부과할 수 있다.
...
6. 이용자의 개인정보를 분실·도난·유출·위조·변조 또는 훼손한 경우로서 제28조 제1항 제2호부터 제5호까지(제67조에 따라 준용되는 경우를 포함한다)의 조치를 하지 아니한 경우
...

핵심은 이렇다.

다른 사람(이하 이용자)의 개인정보를 수집하고 이를 활용하는 자(이하 서비스 제공자)는 이용자의 개인정보를 안전하게 보관하고 처리해야 할 의무가 있다.

만일 (1)개인정보 유출 사고가 발생 했을 때, (2)서비스 제공자가 개인정보 보호를 위한 안전조치의 의무사항을 소홀히 했을 때, 과징금을 부과할 수 있도록 한 것이다.

즉 아래의 두 조건이 모두 만족되었을 때, 과징금 부과가 가능한 것이다.

서비스 제공자 입장에서는 개인정보가 유출되었다 할지라도, 개인정보 보호를 위한 안전 조치를 충실히 했다는 것이 증명되면 과징금 처분을 감경받거나 면제 받을 수 있다는 말이 된다.

그렇다면, 서비스 제공자는 어떤 안전조치 의무사항을 준수해야 할까? 이 역시 법과 시행령을 통해 구체적으로 그 기준을 명시하고 있다.

정보통신망법 기준으로 보면, '제28조(개인정보의 보호조치) 제1항 제2호~제5호'까지의 조치를 해야 한다고 명시하고 있다.

정보통신망법 제28조(개인정보의 보호조치) (법조문 바로가기)

① 정보통신서비스 제공자등이 개인정보를 처리할 때에는 개인정보의 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손을 방지하고 개인정보의 안전성을 확보하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적ㆍ관리적 조치를 하여야 한다.
...
2. 개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치ㆍ운영
3. 접속기록의 위조ㆍ변조 방지를 위한 조치
4. 개인정보를 안전하게 저장ㆍ전송할 수 있는 암호화기술 등을 이용한 보안조치
5. 백신 소프트웨어의 설치ㆍ운영 등 컴퓨터바이러스에 의한 침해 방지조치
...

또한 28조의 각호에 대한 기술적, 관리적 조치에 대한 구체적인 안전조치 방법은 동법 '시행령 제15조(개인정보보호조치)'에 따를 것을 규정하고 있다.

서비스 제공자는 해당 법과 시행령을 기준으로  안전조치 의무를 충실히 해야만 개인정보 유출 사고가 발생해도 무거운 처벌을 받지 않게 된다.

과징금 산정 기준
서비스 제공자에게 금전적인 행정처분은 과징금과 과태료를 통해 이뤄진다.

과징금과 과태료 모두 법을 통해 그 산정 기준을 명시하고 있으며, 과태료 보다는 과징금이 더 무거운 처분에 해당하고 금액도 훨씬 높게 책정된다.

각 법에서는 다음과 같이 과징금 부과 기준을 규정하고 있다.

개인정보보호법(제34조의 2)
: 주민등록번호 유출시 5억원 이하의 과징금 부과

정보통신망법(제64조의3)
: 위반행위와 관련한 매출액의 100분의 3 이하에 해당하는 금액을 과징금으로 부과

정보통신망법의 경우 매출액이 클 수록 과징금 금액도 비례해서 높게 책정되도록 규정하고 있다.

과징금의 구체적인 산정기준을 명시하고 있는 시행령을 살펴보면 다음과 같다.

정보통신망법 시행령 제69조의2(과징금의 산정기준 등) (법조문 바로가기)

① ...(생략) "위반행위와 관련한 매출액"이란 해당 정보통신서비스 제공자등의 위반행위와 관련된 정보통신서비스의 직전 3개 사업연도의 연평균 매출액을 말한다.

종합해보면, 직전 3개년도 연평균 매출액의 최대 3%까지 과징금을 부과힐 수 있다는 말이다.

과징금의 가중 및 감경
법 위반행위의 동기 및 내용, 위반의 정도와 결과 등을 고려하여 과징금을 가중하거나 감경할 수 있다.

또한 해킹 사고로 개인정보가 유출되었을 경우, 자진 신고하면 추가 감경을 해 준다. 관례로 보면 통상 10% 정도 추가 감경을 해 준다.

과징금의 구체적인 산정절차와 가중/감경에 대한 상세한 규정은 정보통신망법 시행령 제69조의2 제4항에 명시한 [별표 8]에서 확인할 수 있다

-> (바로가기) [별표 8] 과징금의 산정기준과 산정절차(제69조의2제4항 관련)

개인정보 유출 통계
지난해(2018년) 행정안전부와 KISA(한국인터넷진흥원)이 공동발간한 '개인정보 실태점검 및 행정처분 사례집'에서는 개인정보보보법이 시행(2011년 9월) 된 이후부터 2017년 말까지의 개인정보 유출 통계를 보여준다.

공공기관과 민간 기업을 합해 총 1억 3,254만건이 유출되었다. 2018년 데이터와 신고하지 않은 건수 까지 합한다면 더 높은 수치를 예상해 볼 수 있다.

5천만명 인구에 1억을 훨씬 상회하는 건수로 유출되었으니 적지 않은 수이다. 물론 중복이 존재하겠지만, 그래도 거의 대부분의 국민의 개인정보가 털렸다고 봐야 되지 않을까 한다.

잊을만 하면 터지는 개인정보 유출 사고와 대량의 유출 건수는, 역설적으로 개인정보 유출에 대한 경각심을 둔화 시키는 결과로까지 이어지는 듯 하다. 대부분의 사람이 자신의 개인정보가 불법적인 유통 경로로 거래되고 있다고 생각할 것이다.

개인정보 보호를 위해 개개인의 신중함도 필요하지만, 그에 앞서 개인정보를 활용하는 서비스 제공자의  보안의식 고취와 견고한 안전조치가 선행되어야 할 것이다.

동(同) 자료의 또 다른 통계(유출 사고 유형별 현황)을 보면 개인정보 유출 사고의 원인으로 해킹이 가장 많이 차지한다는 것을 확인할 수 있다.

해킹 피해(개인정보 유출)에 따른 행정처분 사례
얼마전 다음과 같음 메일을 한통 받았다. 보자 마자 "또 털렸군!"하며 한숨이 나왔다.
 

증말이지...
(혹시나 잊을까봐 그러는지) 잊을만 하면 '니 정보 털렸으니 미안해~'라는 메일이 온다.

원래 사고라는 것이, 아무리 대비한다고 해도 발생하기 마련이라고는 하지만 과연 그런 불가항력적인 요인만 있을까? 서비스 제공자의 보안의식에 문제는 없을까? 과연 수익 대비 보안에 적정한 투자를 하고 있을까? 의아 스럽다.

사실 이 글을 쓰게 된 첫번째 동기도, 이참에 그동안의 굵직한 보안사고에 대한 법적 처분 사례를 확인해 보기 위함이었다. 과연 어떤 처분을 해 왔길래 늘 비슷한 보안 사고가 반복되는지 궁금해서이다.

지금부터 그간 발생한 (해킹 사고로 인한) 개인정보 유출에 대해 행정처분한 사례를 알아보자.

하나투어, 주민등록번호 유출 사고
2017년 9월, 해킹 사고로 인해 49만명의 개인정보가 유출되었고 이 중에서 42만명 가량은 주민등록번호가 포함되어 있었다. 

개인적으로는, 2017년 8월 약 한달간 하나투어 구조진단 컨설팅(해당 건과 관련 없는 부문의 컨설팅)을 나갔었는데 바로 다음달에 사고가 터져 기억이 선명하다.

방통위가 발표한 정확한 피해 규모는 다음과 같다. 주민등록번호가 털렸으니 사태가 꽤 심각했다.

[출처: 방송통신위원회]

이 사건은 개인정보보호법이 적용된 사례로, 주관부처인 행정안전부는 개인정보보호법에 근거하여 다음과 같은 행정처분을 내렸다. 참고로 이 사건은 개인정보보호법 제정 이래 처음으로 과징금이 부과된 사례라고 한다.

(과징금 및 과태료)
- 과징금 3억 2,725만원, 과태료 1,800만원 부과

(시정조치 명령)
- 위반행위 즉시 중지
- 대표(CEO) 및 책임있는 임원(CPO 등)의 특별교육 이수
- 개인정보보호 책임자 및 취급자 대상 정기 교육 실시 및 재발방지 대책 수립
- 처분 통지 날로 부터 30일 이내 시정명령 이행결과 제출

(징계 권고)
- 처분 통지 날로부터 2개월 이내에 대표 및 책임있는 임원에 대해 징계할 것을 권고

본 건의 행정처분 사항의 보다 상세한 내용은 다음의 의결 내용을 확인해 보기 바란다.
> (주)하나투어, 개인정보 유출사고로 행정처분 의결

메가스터디, 100만 개인정보 유출사고
2017년 7월, 메가스터디에서는 해킹 사고로 인해 이용자의 아이디, 이름, 생년월일 등 회원정보 123만3,859건(중복제외 111만7227건)의 개인정보가 유출되었다.

방송통신위원회는 정보통신망법에 근거하여 다음과 같이 행정처분을 내렸다.

(과징금 및 과태료)
- 과징금 2억 1,900만원(자신신고로 과징금 추가 감경 10% 적용), 과태료 1,000만원 부과 

(시정조치 명령)
- 위반행위 즉시 중지
- 재발 방지대책 수립
- 시정명령 처분사실 공표

자세한 사항은 다음을 확인하기 바란다.
> 2018년 제33차 위원회 결과

여기어때, 숙박정보 및 개인정보 유출 사고
2017년 3월, 숙박앱 '여기어때'는 SQL 인젝션 공격으로 인해 회원들의 숙박 예약 정보와 개인정보가 유출되었다. 서비스 이용자의 숙박예약정보 3,239,210건과 회원정보 178,625건이 유출되었으며 숙박 예약을 한 회원 대상으로 4,817건의 음란문자가 전송되었다.

[출처: 방송통신위원회]

방송통신위원회는 정보통신망법에 근거하여 다음과 같이 행정처분을 내렸다. 참고로 이 사건은 개인정보 유출사고 최초로 책임자 징계를 권고한 사례하고 한다.

(과징금 및 과태료)
- 과징금 3억 100만원, 과태료 2,500만원 부과 

(시정조치 명령)
- 위반행위의 중지 및 재발방지대책 수립
- 대표자 및 책임있는 임원에 대한 징계권고, 그 결과를 방통위에 통보
- 시정명령 처분사실 공표

자세한 사항은 다음을 확인하기 바란다.
> 방통위, ㈜위드이노베이션 개인정보 유출사고 엄정 제재

인터파크, 2,500만 개인정보 유출사고
2016년 5월, APT 공격에 의해 인터파크 회원정보가 그야말로 대거 유출되었다.

[출처: 방송통신위원회]

엄청난 규모의 개인정보 유출에 걸맞게 과징금도 역대급으로 높게 책정되었다. 개인정보 유출 사고와 관련해 최대 징수액으로 기록했다. 당시 정보통신망법이 개정(매출액 3%)되어서 법 규정에서의 과징금 상한이 대폭 올라갔기 때문에 가능한 수치였다.

인터파크는 아무리 법 개정이 되었어도 기존의 처분에 비해 너무 과도하다며 형평성 및 비례의 원칙에 어긋난다고 입장을 밝힌바 있다. 인터파크는 행정처분에 불복 소송을 걸었고 1심에서 패소하였다. 이후 재항고를 하여 현재 2심 진행중이라 한다.

(과징금 및 과태료)
- 과징금 44억 8천만원, 과태료 2,500만원 부과 

(시정조치 명령)
- 재발방지대책 수립 및 시행

자세한 사항은 다음을 확인하기 바란다.
> 방통위, ㈜인터파크 개인정보 유출사고 엄정 제재

KT, 연속된 개인정보 유출사고
KT는 2012년에 전산망 해킹으로 인해 870만명의 개인정보를 유출한데 이어, 2014년에도 홈페이지가 해킹을 당해 1,170만건의 개인정보가 유출되었다. 2012년 당시 7억 5천만원 가량의 과징금을 처분 받았고 2014년 유출사고에서는 7천만원 과징금 처분을 받았다.

KT는 2004년에도 개인정보 유출사고가 발생한 것을 포함하면 총 3차례나 사고가 반복된 셈이다.

근데 재밌는 것은, 2014년 사건은 과징금 처분 이후 KT가 불복하여 소를 제기했고 결국 법원으로부터 '7천만원 과징금 취소 판결'을 받아 법원이 행정부(방통위)의 처분을 뒤엎은 결과가 나왔다. 현재 2심 진행중이라 한다.

SK 컴즈, 옥션 대규모 개인정보 유출 사고
2008년 옥션에서는 해킹으로 인해 1,863만건의 개인정보가 유출되었다. 2011년에는 SK 컴즈의 네이트,싸이월드가 해킹을 당해 3,500만건의 개인정보가 유출되었다.

두 경우 모두 행정처분은 따로 없었다. 피해를 받은 이용자와 시민단체 등에 의해 손해배상 소송이 진행되었는데, 옥션의 경우 대법원에서 그(옥션)의 손을 들어줘 최종 원고 패소하였다. SK컴즈의 경우 20여건의 소송이 진행되었는데 일부 승소하고 일부 패소했다고 한다.

기타
앞서 사례들을 포함해서 다음과 같이 정리를 해 보았다.

표를 보면, 관련 법이 제정되기 전에는 행정처분 자체가 없었다는 것을 알 수 있다. 그러나 법이 제정되고 갈수록 강화되어 행정처분의 수위도 점점 높아지고 있는 것 같다.

하지만 과연 피해 규모에 대비해서 적정한 처분인가? 하는 생각이 드는 부분도 있다.

논란의 여지가 분명 있을 것이다.

모든 비즈니스 분야에 있어 과도한 규제나 징계는 산업을 위축시켜 발전을 저해시킬 수 있다. 하지만 모든 것이 통신으로 연결되는 초연결 사회로 갈수록 보안 사고는 엄청난 피해를 야기할 것이다.

보안에 대한 경각심을 일깨우고 기업 스스로가 자발적으로 보안에 적절한 투자할 수 있는 제도/사회/문화적 환경 개선이 시급하다는 생각이 든다.

개인적으로는, 잘못을 했을 때 벌을 주는 것도 필요하지만, 잘 했을 대 상을 주는 법안도 나오길 기대한다. 기업이 보안 강화에 사용하는 것이 비용이 아니라 투자가 될 수 있도록 말이다.

SQL 인젝션은, 웹 보안 하면 가장 대중적으로 언급되는 공격 기법입니다. 

XSS와 함께 쌍두마차급으로 유명한 기법이지요. 꽤 오래전에, 이 공격에 대한 글을 한번 다룬적이 있는데요. 벌써 12년도 더 전이네요. 그때나 지금이나 SQL 인젝션의 공격기법이든 방어기법이든 크게 달라진 것이 없어 보입니다.

> [웹 보안 시리즈] 2. SQL INJECTION

(대부분의 웹해킹이 그렇듯이) 웹 개발의 기본을 잘 이해하고 있다면, SQL 인젝션은 쉽게 이해하고 시도해 볼 수 있으리라 판단됩니다. 이 해킹 공격을 도와주는 자동화 툴도 쉽게 구할 수 있고요.

SQL 인젝션은 손쉽게 공격을 해 볼 수 있는 반면에 공격이 성공했을때그 파급력을 상당할 수 있습니다.

지금부터 알아볼 사례들을 보면, 이 진부한 공격기법이 아직까지 기승을 부리고 있다는 것을 알 수 있습니다.

SQL 인젝션 해킹 사례

먼저 SQL 인젝션으로인한 해킹 사례를 집어 보자. 국내의 비교적 최근에 발생한 가장 유명한 두 가지 사례를 먼저 알아보자.

사례1) '여기어때' 해킹

> https://news.joins.com/article/21628794

2017년 3월, 유명한 숙박앱인 '여기 어때'가 해킹을 당했다. 대량의 고객 정보와 고객의 투숙정보가 해커에게 유출되었으며 이 중 수천명에게 '모텔서 즐거우셨나요?'라는 식의 협박성의 민망한 문자가 전송되었다고 한다.

기사에 따르면, 이 사건은 보안이 허술한 특정 웹 페이지를 대상으로 SQL 인젝션 공격을 시도해서 관리자 세션을 탈취하고 이 정보로 관리 페이지에 위장 로그인하여 고객의 개인정보를 유출했다고 한다.

> ‘여기어때’ 개인정보 99만건 유출…‘SQL인젝션’ 공격이 원인

사례2) '뽐뿌' 해킹

'여기 어때'  사건으로부터 약 2년전(2015년 9월), 커뮤니티 사이트로 유명한 '뽐뿌'에서도 SQL 인젝션 공격으로 200만명 가량 개인정보가 유출된 사례가 있었다.

> http://www.korea.kr/policy/pressReleaseView.do?newsId=156081058

이러한 개인정보 유출은 해당 사이트에 대한 피해뿐만 아니라, 이미 유출된 개인정보가 언제 어떤 식으로 다시 악용되어 2차 피해로 이어질지 알 수 없다는 것이 더욱 문제이다.

사례3) 해외 사례

SQL 인젝션 해킹 사례는 비단 국내에만 있는 것이 아니다.

2015년, 해커그룹 어나미머스가 WTO 웹사이트를 SQL 인젝션으로 공격해 각 나라의 직원 개인정보를 탈취한 사건이 있었다.
> 어나니머스, WTO 웹사이트 공격…직원 정보유출

또한 2014년, 영국의 유명 여행 웹사이트가 SQL 인젝션 공격으로 신용카드 번호가 유출되었다고 한다.> 英정보위원회 SQL인젝션 공격 경고…피해사례 발생

그리고 2011년에는 소니가 해커집단(Lulzsec)으로부터 조롱당한 일이 있었는데, 이때도 역시 SQL 인젝션 기법이 사용되었다고 한다.
> 미국 FBI, 소니 해킹 용의자 검거

이외에도 조금만 찾아보면 SQL 인젝션으로 인한 다양한 해킹 사례를 확인할 수 있다.

SQL 인젝션 공격 비중

앞서 XSS와 함께 SQL 인젝션은 쌍두마차 격으로 웹에서 빈번히 일어나는 해킹 기법이라고 했다. 2016년 펜타시큐리티에서 발표한 '웹 공격 동향 보고서'를 살펴 보자

전체 해킹 시도 중, SQL 인젝션이 45% 즉 절반에 가까운 비중을 차지했다. 펜타시큐리티 측은 2016년 발생한 웹공격 사례 4건 중 3건이 SQL 인젝션과 XSS 기법으로 수행됐다는 조사결과를 발표했다.

그리고 글로벌 CDN업체인 CDNetworks의 '2016년 4분기 웹 공격 분석 보고서'를 보면 SQL 인젝션이 두 번째로 많이 시도되는 해킹 기법이라는 조사 결과를 내놨다.

SQL 인젝션의 위상(?)은, OWASP TOP 10에서도 확인할 수 있다.

OWASP Top 10은 2013년에 이어 개정한 2017년 버전에서도 '인젝션'이 랭킹 1위로 포지셔닝 하고 있다. 물론 OWASP에서 말하는 인젝션은 SQL 인젝션을 포함한 모든 유형의 인젝션을 일컫는다.

SQL 인젝션 개념

SQL 인젝션은, 웹 애플리케이션이 데이터베이스와 연동하는 모델에서 발생 가능하다.

이용자의 입력값이 SQL 구문의 일부로 사용될 경우, 해커에 의해 조작된 SQL 구문이 데이터베이스에  그대로 전달되어 비정상적인 DB 명령을 실행시키는 공격 기법이다.

[출처: 행정안전부 시큐어 코딩 가이드]

SQL 인젝션 공격 목적 및 영향

SQL 인젝션은 DB에 비정상적인 쿼리가 실행되도록 하여 다음과 같은 목적을 달성하고자 한다.

1. 인증 우회
SQL 인젝션 공격의 대표적인 경우로, 로그인 폼(Form)을 대상으로 공격을 수행한다. 정상적인 계정 정보 없이도 로그인을 우회하여 인증을 획득할 수 있다.

2. DB 데이터 조작 및 유출
조작된 쿼리가 실행되도록 하여, 기업의 개인정보나 기밀정보에 접근하여 데이터를 획득할수 있다. 또한 데이터 값을 변경하거나 심지어 테이블을 몽땅 지워버릴 수도 있다.

3. 시스템 명령어 실행
일부 데이터베이스의 경우 확장 프로시저를 호출하여 원격으로 시스템 명령어를 수행할 수 있도록 한다. 시스템 명령어를 실행할 수 있다면 해당 서버의 모든 자원에 접근하고 데이터를 유출, 삭제 할 수 있다는 말이 된다.

SQL 인젝션 공격 원리와 유형

SQL 인젝션은 데이터베이스 명령어인 SQL 쿼리문에 기반하여 공격을 수행한다. 공격에 이용되는 쿼리문은 문법적으로는 지극히 정상적인 SQL 구문이다. 다만 실행되지 말아야 할 쿼리문이 실행되어 공격에 이용되는 것이다.

SQL 인젝션은 최소한 다음의 조건을 충족해야 공격이 가능하다.

조건 1) 웹 애플리케이션이 DB와 연동하고 있다.

조건 2) 외부 입력값이 DB 쿼리문으로 사용된다.

웹 애플리케이션이 위 두 조건 중, 하나라도 충족하지 않는다면 SQL 인젝션 공격은 무용지물이 될 것이다. 그러나 현재의 대부분 웹 애플리케이션은 위 두가지 조건을 대부분 충족한다. 그래서 대부분의 경우 SQL 인젝션은 유효한 공격 기법이 될 것이다.

SQL 인젝션 공격 유형과 공격 기법

1. (일반적인) SQL 인젝션

굳이 '일반적인'이라는 용어는 붙일 필요가 없으나, 이어서 소개할 Blind SQL 인젝션과 구분하기 위함이다. 일반적인 SQL 인젝션 공격은 다음의 형태로 수행된다.

1) 쿼리 조건 무력화(Where 구문 우회)
Where 구문은 SQL에서 조건을 기술하는 구문이다. Where 조건에 기술된 구문이 '참(true)'이 되는 범위만 쿼리 결과로 반환된다.

해커는 이 Where 조건이 무조건 참이 되도록 쿼리를 조작하여 Where 조건을 우회하게 만든다.

예를 들어, 다음과 같이 로그인을 처리하는 동적쿼리가 있다고 가정하자. 외부 입력값인 UserID와 Password가 쿼리문의 일부로 사용되고 있다.

먼저 SQL 구문의 주석(Comment)을 의도적으로 삽입하여 Where 조건을 무력화 시킬 수 있다. 다음과 같이 UserID 값에 주석을 삽입하면 주석 이하의 구문은 실행되지 않게 되어 admin이라는 계정의 패스워드를 몰라도 인증을 통과하게 된다. (admin이라는 ID는 이미 알고 있다고 가정한다. 그리고 -- 는 MS SQL Server의 주석이다. MySQL의 경우 #을 사용해야 한다.)

또한 항상 참이 되도록 Boolean 식을 구성하여 Where 조건을 무력화 시킬 수 있다. 다음과 같이 Password 값에 참(true)인 조건이 or 로 연결되도록 삽입하면 or 조건으로 인해 쿼리의 결과가 무조건 참이되어 없는 계정과 다른 패스워드라 할지라도 (여기서는 test라는 계정은 실제 db에 없는 계정임) 인증을 통과하게 된다.

이와 같은 방식을 이요하여 인증을 우회하기도 하지만, 직접 데이터베이스 내용을 조작할 수도 있다. 다음과 같이 ;(콜론)으로 명령어를 연결하면 한 줄로 된 두 개이상의 명령어를 연속해서 기입할 수 있는데 여기에 테이블을 삭제하거나 수정하는 조작된 쿼리문을 삽입할 수 있다.

2) 고의적 에러 유발후 정보 획득
또다른 기법으로는 의도적으로 SQL 구문 에러를 유발하여 웹 애플리케이션이 내뱉은 오류 정보에 기반하여 유용한 정보를 알아 차린다. 그 정보는 연속되는 또 다른 공격의 소재로 사용되기도 한다.

기본적으로 웹 애플리케이션은 쿼리 수행 중 오류가 발생하면 DB오류를 그대로 브라우저에 출력한다. 이 오류 정보를 통해 DB의 스키마 정보나 데이터가 유출될 수 있다.

가령, SQL 쿼리문에서 UNION 은 두 테이블의 결과를 합치는 명령어이다. UNION으로 합쳐지는 두 테이블은 컬럼 갯수가 일치해야만 오류가 나지 않는다. 아래와 같이 컬럼 1개만 가진 대상 테이블을 가정하여 UNION 구문을 삽입해 보자.

테스트용 Users 테이블은 4개의 컬럼으로 구성되어 있다. 따라서 위의 쿼리문이 실행되면 다음과 같은 오류가 발생하여 브라우저에 노출된다.

"UNION, INTERSECT 또는 EXCEPT 연산자를 사용하여 결합된 모든 쿼리의 대상 목록에는 동일한 개수의 식이 있어야 합니다." (SQL Server 기준)

컬럼 수가 몇개인지 모르는 해커는 하나부터 둘,셋,.. 늘리면서 입력을 반복해서 시도해 볼 것이다. 마침 4개의 UNION SELECT를 하는 순간 오류가 발생하지 않음을 알고 이 기능의 원본 쿼리가 반환하는 컬럼의 수가 4개인 것을 알게 된다. (참고로 MS SQL Server에서는 UNION 되는 컬럼끼리 데이터 타입이 충돌나면 타입 오류를 발싱시키므로 컬럼 타입을 맞출 필요가 있다.)

이렇게 알아낸 컬럼 수를 기반으로 다음과 같이 시스템 테이블의 정보를 조회해 볼 수 있다. 다음의 쿼리가 실행되도록 SQL 구문을 주입하면 현재 데이터베이스에 존재하는 모든 테이블 목록을 볼 수 있다.
(아래 쿼리는 SQL Server 기준이다. 만일 MySQL이라면 information_scheme 데이터베이스의 테이블들을 사용하면 된다.)

위와 같이 테이블 리스트 조회에 성공했다면, 테이블 목록 중 구미가 당기는 테이블을 선택해서 그 테이블에 저장된 데이터를 획득할 수 있다. 다음의 예에서는 결제(Payment)로그가 담긴 PaymentLog 테이블의 UserID와 카드 번호 유출을 시도하는 쿼리이다.

물론 이렇게 공격에 성공하려면 컬럼명도 알고 때론 타입도 알아야 할 경우가 생긴다. 과거에 정리했던, 아래의 글에서 컬럼명을 알아내거나 타입을 알아내는 방법을 참고하도록 한다.

> [웹 보안 시리즈] 2. SQL INJECTION

3) 시스템 명령어 실행
MS SQL Server의 경우 시스템 명령을 실행할 수 있는 확장 프로시저를 제공한다. xp_cmdshell 프로시저를 이용한다. 다음과 같이 UserID 값에 ;(콜론)으로 xp_cmdshell 실행 구문을 연결하고 이후 구문은 주석처리 되도록 하여 윈도우 C 드라이버를 탐색하는 명령을 보낸다. 이 계정에 유효한 권한이 주어져 있다면 어떤 시스템 명령도 내릴 수 있게 된다.

참고로 각 DBMS마다 SQL 구문이 조금식 차이가 나므로, SQL 인젝션 공격시 해당 DBMS가 지원하는 구문을 잘 알고 사용해야 한다. 다음의 사이트에서 각 DBMS별로 서로 상이한 구문을 상세히 안내하고 있으니 참고 바란다.

> SQL Injection Cheat Sheet

2. Blind SQL 인젝션

앞서 일반적인 SQL 인젝션 공격에서는 쿼리 조건을 무력화하여 인증을 우회하거나, 출력된 에러 내용에 기반하여 DB의 스키마 정보를 획득한 후, 쿼리 결과에 정보를 붙여서(UNION) 데이터를 유출하거나 시스템 명령어를 삽입하는 형태로 공격이 진행되었다.

그러나 만일 공격하는 대상 웹페이지가 어떠한 오류도 출력하지 않고 쿼리 결과 리스트도 제공하지 않는다면 이러한 공격 패턴으로는 해킹에 성공하기가 쉽지 않다. (다시말해, 에러 내용으로 DB 정보를 유추할 수도 없고, 쿼리 결과 데이터를 제공하지 않기 때문에 UNION 같은 쿼리를 삽입하여 데이터를 붙여 볼 수도 없는 것이다.)

이럴 경우, 유용하게 사용할 수 있는 공격 기법이 바로 Blind SQL 인젝션이다. 

한마디로, Blind SQL 인젝션은 쿼리 결과의 참/거짓으로부터 DB값을 유출해 내는 기법이다.

이 공격을 수행하려면, 먼저 웹 애플리케이션에서 쿼리 결과에 대해 참/거짓을 반환하는 요소를 찾아야 한다. 예를 들어 'ID 찾기'나 '게시판 검색'과 같은 기능에서 참/거짓을 판별하는 요소를 찾을 수 있다.

1) Boolean-based Blind 공격
가령 어느 웹사이트가 게시판 검색이라는 기능을 제공할 경우, 다음과 같이 참/거짓의 반환을 테스트 해 볼 수 있다.

'hello'라는 검색어에 항상 참인 조건(1=1)을 AND로 조합하니까 정상적으로 결과가 반환되었다. 반면 동일한 검색어(hello)에 항상 거짓인 조건(1=2)을 AND로 조합하니가 구성하니 게시판 검색이 되지 않았다. 이 둘을 참과 거짓의 반응으로 간주할 수 있다.

즉 핵심은 게시판 검색 기능을 참/거짓을 반환하는 요소로 사용할 수 있다는 점이다. 여기에 AND 조건으로 해커가 알고 싶은 쿼리 조건을 삽입해서 그 결과로부터 정보유출이 가능한 것이 Blind SQL 인젝션 공격 기법이며 이중에서도 AND 조건에 논리식을 대입하여 참/거짓 여부를 알아내는 방식을 Boolean-based Blind 공격이라 한다.

2) Time-based Blind 공격
앞서 게시판 검색에서는 검색 결과의 유,무로 참/거짓을 판별할 수 있었다. 그러나 어떤 경우에는 응답의 결과가 항상 동일하여 응답결과만으로는 참/거짓을 판별할 수 없는 경우가 있을 수 있다.

이럴때는 시간을 지연시키는 쿼리를 주입하여 응답 시간의 차이로 참/거짓 여부를 판별할 수 있다.

게시판 검색 시나리오에서 Time-based Blind 공격을 시도해 보자.

이렇듯 Time-based Blind 공격은 쿼리 지연을 유도해 응답 시간에 걸리는 시간으로 참/거짓을 판별하게 함으로써 DB의 유용한 정보를 캐낼 수 있게 된다.

정리하자면, Blind SQL 인젝션은 쿼리 결과가 참일때와 거짓일때의 서버의 반응 만으로 데이터를 얻어낼 수 있는 SQL 인젝션 공격 기법이다. 이 기법은 많은 조건에 대한 비교과정을 거쳐야 의미있는 정보를 얻을수 있기 때문에, 거의 모든 경우 자동화 툴을 사용해서 공격이 진행된다.

Blind SQL 인젝션 공격 시나리오

해커는 게시판 검색 기능을 이용하여 회원 테이블의 비밀번호를 알아내고자 한다. 이미 다양한 공격 시도로 회원 테이블명이 Users라는 것을 알고 있거나 유추했다고 가정한다.

1. (앞서 해 본 것 처럼) 해커는 게시판 검색 기능으로 참/거짓을 판별할 수 있다는 것을 알아 냈다.

2. 해커는 회원 테이블에서 특정 회원의 비밀번호를 알아내고자 다음과 같은 쿼리를 주입한다.

회원 테이블에서 'admin'이라는 계정의 패스워드를 알아 내려고 한 해커는....

항상 참(true)을 반환하는 조건(여기서는 게시판 제목 검색에 'hello'라는 검색어) 뒤에 AND 조건으로 회원 테이블의 패스워드에서 첫 문자를 가져와서 아스키코드로 변환하여 그 결과를 아스크 코드값과 비교한다. 먼저 대소분자 여부를 알아내기 위해 아스크 코드 91 보다 큰지 검사한다.

아스키코드 90은 대문자 'Z'의 아스키 값으로 이 값보다 크다는 말은 패스워드 첫 글자가 소문자로 구성되었다는 의미가 된다.(아스키 코드 테이블 참조)

패스워드 첫 글자가 소문자인 것을 알아낸 해커는 계속해서 다음과 같은 공격을 연속적으로 시도한다.

이렇게 총 6번을 시도해 본 결과, 패스워드 첫 글자가 소문자 'P' 라는 것을 알게 된다.
(111보다 크다는 조건에서는 true 값을, 112보다 크다는 조건에서는 false를 반환했으니 결과는 112로 영어 소문자 p가 되는 것이다)

이런식으로 한 글자씩 아스키값을 비교해서 전체 패스워드를 알아 나가는 방식으로 공격이 수행된다. 

SQL 인젝션 공격 실습

SQL 인젝션 취약성 판단

SQL 인젝션 공격을 시도하기 전에 공격 대상 웹 애플리케이션이 SQL 인젝션에 취약한지 먼저 알아 보는 것이 좋다. 보통 자동화 툴을 통해 스캐닝을 한번 쭉 해 보면 쉽게 알 수 있지만 간단한 테스트로도 알아 볼 수 있다. 

제일 간편하게 알아 볼 수 있는 방법은 사용자 입력값에 '(싱글쿼터)를 주입해 보는 것이다.

만일 싱글쿼터를 입력했는데, 사이트가 오류를 내 뱉으면 SQL 인젝션에 취약하다는 의미가 된다. 공격 대상 웹 애플리케이션의 다음과 같은 입력요소에 싱글쿼터 주입을시도해 볼 수 있다.

- 로그인 창
- 게시판 검색창
- 사이트 전역 검색창
- GET URL의 파라메타값
- 기타 외부입력값으로 보이는 모든 곳

DVWA 사이트에서 SQL 인젝션 공격 실습

1) (일반적인) SQL 인젝션 공격 실습

로컬에 셋팅된 DVWA 사이트(http://localhost/dvwa)를 브라우저로 접속하고 로그인(admin / password) 한다. 만일 DVWA 사이트에 접속되지 않는다면 XAMPP Control Panel에서 Apache와 MySQL 이 시작되었는지 확인한다.

DVWA 사이트에 접속하면 다음 화면과 같이 SQL Injection과 SQL Injection(Blind) 메뉴를 볼 수 있다. 먼저 SQL Injection 메뉴를 들어가서 SQL 인젝션 공격을 시도 해보자.

이 페이지는 User ID를 입력하면 회원 정보를 간단히 출력하는 기능을 제공한다.
(DVWA 데이터베이스는 1~5까지의 User ID가 기본적으로 저장되어 있다. 1~5 중 아무거나 입력해서 테스트 해 보면 출력 결과를 볼 수 있다)

User ID라는 외부 입력값을 주입할 수 있는 기능을 찾았으니 이 페이지가 SQL 인젝션에 취약한지 먼저 테스트 해 본다. 앞서 설명 했듯이, '(싱글쿼터)를 입력해서 응답을 보니 오류 메시지가 출력되는 것을 확인할 수 있다. 따라서 이 페이지는 SQL 인젝션에 취약한 것을 확인한 것이다.

이제 User ID에 공격용 SQL 구문을 삽입해 보자. DVWA 사이트는 MySQL DB를 사용하므로 MySQL용 SQL 구문을 사용해야 한다.

다음은 SQL 구문 삽입에 대한 결과를 설명한다

1' or 1=1#  (결과)모든 User 정보가 노출되어 버림(조건이 항상 참이 되어 버려 모든 행(row) 출력)

1' union select 1,1# (결과)오류 없음. 즉 컬럼 갯수가 두개라는 것을 알아냄

1' union select schema_name, 1 from information_schema.schemata# (결과)서버의 데이터베이스 이름이 모두 노출됨

1' union select table_name, column_name from information_schema.columns where table_schema = 'dvwa'# (결과)dvwa 데이터베이스에 포함된 테이블과 컬럼이름이 모두 노출됨.

(MySQL의 information_schema는 해당 서버의 모든 DB의 메타정보를 저장해둔 데이터베이스이다. UNION 구문을 주입하여 information_schema에 있는 각종 정보를 조회해 볼 수 있다.)

이제 앞서 공격을 통해, dvwa라는 DB에 users라는 테이블이 있으며 이 테이블의 컬럼들을 모두 알아 내었다. 마지막 공격 테스트로 다음과 같이 users 테이블에 user 이름과 password를 조회해 보자

1' union select user,password from users# (결과) users 테이블의 모든 사용자에 대한 이름, 패스워드가 노출됨

2) Blind SQL 인젝션 공격 실습

이제 DVWA 사이트에서 Blind SQL Injection 메뉴로 이동하자. SQL Injection 메뉴와 동일하게 User ID를 입력받는 페이지가 로딩된다.

여기에 '(싱글쿼터)를 입력해보자. 

이번에는 아무런 오류가 나지 않는다. 즉 SQL 인젝션 공격에 취약한지 일단을 알기 힘들다.

그리고 정상적인 User ID를 입력해도 '아이디가 존재한다'는 안내 메시지만 노출될 뿐 특별한 추가 정보를 보여주진 않는다.

그렇다면 이제 이 페이지가 참/거짓을 판별할 수 있는 요소인지 테스트 해 보자. User ID에 다음과 같이 입력하고 결과를 보자.

1' AND a=b# (결과) User ID가 없다는 결과를 출력함

1' AND a=a# (결과) User ID가 존재한다는 결과를 출력함

존재하는 ID인 1을 입력하고 AND 조건으로 항상 참(true)이되거나 거짓(false)이 되는 조건을 주입하니까 그 결과로 서로 다른 결과를 보여준다. 여기서 우리는 이 페이지가 Blind SQL 인젝션에 활용할 수 있는 즉 참/거짓을 반환하는 요소임을 눈치 챌 수 있다.

이제 다음과 같이 Time based 공격을 시도해 보자.

1' AND sleep(5)# (결과) 응답시간이 5초가 걸림

6' AND sleep(5)# (결과) 즉각 응답함

존재하는 ID일 경우, 응답에 5초가 걸리는 것으로 보아 이 조건은 참이 되어 1이라는 ID가 존재한다는 의미가 된다. 반면 6을 입력하면 거짓이 되어 그 뒤의 조건인 sleep(5)가 실행되지 않아 즉각 반환하게 된다. 결국 여기서 우리는 6이라는 User ID는 존재하지 않는다는 것을 알 수 있다.

이제 참/거짓을 판별할 수 있는 요소를 이용해서 유용한 정보를 캐내어 보자

User ID가 1인 사람의 first_name을 알아 내는 과정을 시도해보자. 아래처럼 차례대로 입력해서 결과를 보자.

1' and ascii(substr(select first_name from users where user_id='1'), 1, 1) > 91# (결과) false

1' and ascii(substr(select first_name from users where user_id='1'), 1, 1) > 110# (결과) false

1' and ascii(substr(select first_name from users where user_id='1'), 1, 1) > 100# (결과) false

1' AND ascii(substr((select first_name from users where user_id='1'), 1, 1)) > 95# (결과) true

1' AND ascii(substr((select first_name from users where user_id='1'), 1, 1)) > 97# (결과) false

1' AND ascii(substr((select first_name from users where user_id='1'), 1, 1)) > 96# (결과) true

96보다는 크고(true) 97보다는 크지 않는 아스키코드의 문자는 바로 'a'가 된다. 이렇게 first_name의 첫 글자를 알아 내었다. 이런식으로 두번째, 세번째 글자를 하나씩 알아낼 수 있게 된다.

3) 툴을 이용한 자동화된 Blind SQL 인젝션 공격 실습

앞서 수동으로 Blind SQL 인젝션 공격을 시도해 보았다. first_name 하나만 알아내는데도 많은 비교 과정을 거쳐야 한다. 따라서 이와같은 공격은 툴로 자동화해서 시도하면 공격 효율이 훨씬 높아진다.

SQL 인젝션에 가장 흔히 사용되는 툴인 SQL Map를 사용해 볼 것이다.

SQL Map 으로 다음의 명령을 실행할 것이다.

여기서 공격 대상 URL은 DVWA 사이트의 Blind SQL Injection 메뉴에서 User ID를 입력하고 전송(Submit)한 URL이 되며, 쿠키 정보는 크롬 브라우저 개발자도구(F12)에서 확인 가능하다.
(DVWA 사이트는 인증을 해야 들어갈 수 있기 때문에 인증값인 쿠키가 필요하다.)

이 명령어를 채워서 다음과 같이 공격을 시작해 보자.

python sqlmap.py -u "http://localhost/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; _ga=GA1.1.1921041872.1534152252; PHPSESSID=8dknegkogthdhj1ibr615f9iqn"

다음과 같은 콘솔 결과를 확인할 수 있다.

콘솔의 내용을 보면, id라는 GET 파라메타를 이용해서 AND Boolean-based Blind 공격이 가능할 것 같다는 메시지를 확인할 수 있다. 그리고 데이터베이스가 MySQL 같아 보이며, 다른 DBMS에 대한 공격은 건너 뛸 것인지 물어보고 있다. 여기서 Y(기본값)를 입력하고 엔터를 친다.

그러면 다음과 같이 선택을 요구한다.

for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n]

MySQL 대한 모든 테스트를 포함할 것인지 두는 것인데 역시 Y(기본값)을 선택하고 다시 엔터를 친다.

이제 SQLMap이 공격을 자동을 수행한다. 중간중간에 옵션에 대한 질문이 나오면 기본값(Y)로 해서 계속 진행한다.

최종적으로 다음과 같이, id 파라메타가 취약하다는 것을 알리며 다른 파라메타를 계속 테스트 할 것인지 물어본다. 

GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N]

여기서는 N(기본값)을 선택하고 계속 진행하면 최종 결과가 다음과 같이 나타난다.

id 파라메타를 이용해서 boolean-based blind와 error-based, AND/OR time-based blind 공격이 가능하다고 알려 주고 있으며 웹서버의 종류와 버전, 개발언어, DBMS 종류와 버전을 알려준다.

이제 SQL 인젝션 공격이 가능하다고 나왔으니 본격적으로 공격을 시도해 보자.

DB 명 알아내기
다음 명령어를 실행해서 DB 명을 알아 낼 수 있다.

python sqlmap.py -u "http://localhost/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; _ga=GA1.1.1921041872.1534152252; PHPSESSID=8dknegkogthdhj1ibr615f9iqn" --current-db

명령이 실행되면 콘솔 출력에 다음과같이 DB명이 나타난다.

current database:    'dvwa'

테이블명 알아내기
DB명을 알아 냈으니 이번에는 다음의 명령어로 해당 DB에 존재하는 테이블들을 조사해 보자.

python sqlmap.py -u "http://localhost/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; _ga=GA1.1.1921041872.1534152252; PHPSESSID=8dknegkogthdhj1ibr615f9iqn" -D dvwa --table

결과를 보면 dvwa 데이터베이스에는 guestbook과 users라는 테이블이 존재한다는 것을 확인할 수 있다.

테이블에 저장된 데이터 알아 내기
users가 회원테이블임을 직감하고 이 테이블의 내용을 획득하고자 한다. 다음의 명령어를 실행한다.

python sqlmap.py -u "http://localhost/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; _ga=GA1.1.1921041872.1534152252; PHPSESSID=8dknegkogthdhj1ibr615f9iqn" -T users --dump

결과는 users 테이블에 저장된 모든 회원정보가 나타난다. 샘플 화면에는 admin, Brown 이라는 사용자가 있고 패스워드가 해시된 형태로 저장되어 있음을 확인할 수 있다.

이어서 SQLMap은 다음과 같이 해시된 패스워드를 사전 공격(Dictionary Attack)으로 크래킹 시도를 할 것인지 물어본다. 이때 어떤 사전(Dictionary)파일을 사용할 것인지 확인한다. 모두 기본값으로 계속 진행한다.

해시된 패스워드를 사전 공격으로 하나씩 크래킹을 시도한다.

공격 시도가 완료되었다. 결과를 보면 users 테이블의 모든 내용이 출력되었으며 해시된 패스워드도 크래킹되어 평문으로 노출되었다. 그리고 친절하게도 csv 파일로 저장했다고 알려 주고 있다.

테스트 시나리오 이지만, 이런 식으로 회원테이블이 유출되면 정말 끔찍할 것이다.

SQL 인젝션 대응 방안

SQL 인젝션 공격에 대응하기 위한 방법들을 알아보자. 여러 측면에서 전방위적인 대응이 필요하겠으나 여기서는 기술적인 부분만 다루도록 한다. 다음은 3가치 축으로 정리해 본 모습이다.

웹 방화벽(WAF) 도입

웹 방화벽은 HTTP/HTTPS 응용 계층의 패킷 내용을 기준으로 패킷의 보안성을 평가하고 룰(Rule)에 따라 제어한다. SQL 인젝션의 룰(Rule)을 설정하여 공격에 대비할 수 있다.

1. 물리적 웹 방화벽
기업의 규모가 어느정도 되거나 보안이 중시되는 환경 또는 예산이 충분한 환경에서는 물리적인 전용 WAF 사용을 권장한다. 어플라이언스 형태의 제품을 사용하거나 SECaaS 형태의 클라우드 기반의 솔루션을 도입할 수도 있다.

2. 논리적 웹 방화벽(공개 웹 방화벽)
전용 웹방화벽 장비를 도입할 여력이 되지 않는다면, 공개 웹방화벽을 고려해 볼 만 하다. 대부분 공개 웹 방화벽은 물리적인 장비가 아닌 논리적인 구성으로 웹 방화벽 역할을 수행한다.

윈도우 서버 환경에서는 WebKnight, 아파치 서버 환경에서는 ModSecurity를 사용할 수 있다.

시큐어 코딩

1. 입력값 유효성 검사

모든 웹 보안 영역에서는 외부 입력값에 대한 대전제가 하나 있다.

모든 외부 입력값은 신뢰하지 말라

SQL 인젝션에서도 마찬가지이다. 외부에서 들어오는 모든 입력값은 모두 의심의 대상이다.
여기서 외부 입력값은 이용자가 직접 타이핑한 값일 수도 있지만 직접 타이핑 하지 않더라도 Burp Suite와 같은 프록시 툴을 이용하여 중간에 값을 변조할 수 있는 외부 값도 포함된다. (가령 게시판에서 게시물 번호와 같은..)

SQL 인젝션의 가장 기본적인 대응 전략은 바로 입력값의 유효성을 검사하는 것이다. 입력값 검증에는 두 가지 방식이 존재한다.

1) 블랙 리스트 방식
SQL 쿼리의 구조를 변경시키는 문자나 키워드를 제한하는 방식이다. 아래와 같은 문자를 블랙리스트로  미리 정의하여 해당 문자를 공백 등으로 치환하는 방식으로 방어한다.

2) 화이트 리스트 방식
블랙리스트 방식보다 보안성 측면에서는 훨씬 강력한 방법이다. 블랙리스트 방식에서는 금지된 문자 외에는 모두 허용하지만 화이트리스트 방식에서는 허용된 문자를 제외하고는 모두 금지하는 방식이다. 

지정된 문자만을 허용하기 때문에 웹 애플리케이션의 기능에 따라 화이트리스트를 다르게 유지해야 할 필요가 생긴다. 그리고 

참고로 화이트 리스트를 정의할 때에는 개별 문자를 일일이 하나씩 모두 정의하는 것보다 정규식을 이용해서 범주화/패턴화 시키는 것이 유지보수에 더 유리하다.

2. 동적 쿼리 사용 제한

1) 동적 쿼리 금지
웹 애플리케이션이 DB와 연동할 때 정적쿼리만 사용한다면 SQL 인젝션을 신경 쓸 필요가 없다. 하지만 현실적으로 동적 쿼리를 사용하지 않을 수 없을 것이다. 근래의 웹 애플리케이션은 모두 사용자와 상호작용하며 동적인 기능을 기반으로 하기 때문에 동적 쿼리 사용은 거의 필수에 가깝다.

2) 매개변수화된 쿼리(구조화된 쿼리) 사용
동적 쿼리를 정적쿼리 처럼 사용하는 기법이다. 쿼리 구문에서 외부 입력값이 SQL 구문의 구조를 변경하지 못하도록 정적구조로 처리하는 방식인데 이를 파라메타화된(매개변수화된) 쿼리라 한다.

자바 환경에서 JDBC API를 사용하는 경우, 구조화된 쿼리를 지원하는 PreparedStatement를 사용할 수 있다. 닷넷에서는 SqlCommand를 사용하면 파라메타화된 쿼리를 사용할 수 있다.

추가로 행정안전부에서 발간한 시큐어코딩 가이드를 보면 자바 기준에서 JDBC, MyBatis, Hibernate 사용환경에서 안전한 코딩 기법을 제시하고 있으니 참고 바란다.

> 시큐어 코딩 가이드

3. 오류 메시지 출력 제한

1) DB 오류 출력 제한
DB의 오류 정보를 그대로 이용자에게 노출해서는 안된다. DB 오류 정보에는 개발자들이 쉽게 디버깅할 수 있도록 내부 정보를 상세히 알려주는 경우가 많다. 해커는 이 정보를 바탕으로 DB 구조를 파악하고 데이터 유출을 시도할 것이다. 따라서 DB 오류가 적나라하게 이용자에게 노출되지 않도록 커스텀 오류 페이지를 제공해야 한다.

2) 추상화된 안내 메시지
또한 너무 자세한 안내 메시지도 주의할 필요가 있다. 가령 로그인을 실패 했을 때, ID가 틀렸는지 Password가 틀렸는지 꼭 집어 알려줄 필요가 있을까? 오히려 이 정보는 해커들에게 공격의 범위를 좁혀주는 결과로 이질 수 있다. 단지 '로그인 정보가 일치하지 않습니다'와 같이 추상적인 메시지가 (약간의 사용성을 해치더라도) 더 나을  때도 있다.

DB 보안

1. DB 계정 분리
관리자가 사용하는 DB 계정과 웹애플리케이션이 접근하는 DB 계정은 반드시 분리되어야 한다. 간혹  귀찮다는 이유로 관리자의 DB계정을 여기저기 다 사용하는 경우가 있다. 반드시 분리 하도록 한다.

2. DB 계정 권한 제한
웹 애플리케이션이 DB에 액세스하는 전용 계정을 생성하고 이 계정에는 최소 권한 원칙에 입각하여 꼭 필요한 권한만 할당한다. 과연 웹애플리케이션에서 DROP TABLE와 같은 DML을 실행할 필요가 있는가? 아마 대부분은 필요치 않을 것이다. 또한 웹에서 DB의 기본 프로시저나 확장 프로시저를 호출할 필요가 있는가도 따져 볼 일이다.

웹 애플리케이션이 제공하는 기능만 수행가능하도록 권한을 제한한다.

참고로 필자의 과거 경험을 보자면, 모든 DB 액세스는 저장 프로시저로만 가능하도록 하고 계정 권한은 해당 프로시저들의 실행 권한만 부여한 적이 많았다.

또 한가지 팁은, SELECT 권한과 INSERT, UPDATE, DELETE 권한을 분리하여 서로 다른 계정으로 접근하도록 구성할 수도 있다. 이 경우 SELECT 권한으로 SQL 인젝션 공격이 들어와도 데이터베이스를 업데이트 할 수 없게 된다.

3. 기본/확장 저장 프로시저 제거
데이터베이스가 설치될때 기본적으로 포함된 프로시저들을 꼭 필요한 경우가 아니라면 제거하는 것이 좋다. 가령 MS SQL Server의 xp_cmdshell 프로시저는 db에서 시스템 명령어를 실행할 수 있도록 하는 확장 프로시저이다. 거의 대부분의 웹 애플리케이션에서는 이러한 확장 프로시저를 호출할 필요가 없을 것이다.

취약점 점검과 모니터링

1. 지속적 취약점 점검
SQL 인젝션 취약점을 정기적으로 점검해야 한다.

모의 해킹을 시도하거나 웹 취약점 점검 툴을 이용해 주기적인 취약점 점검이 권장된다.

비즈니스가 활발히 진행되는 만큼 웹사이트의 업데이트도 빈번할 것이다. 간단한 이벤트 페이지라고 하더라도 DB연동을 하는 경우, 언제나 SQL 취약점에 노출될 수 있다는 것을 명심해야 한다. 

다른 모든 곳에 보안을 튼튼해 해 뒀더라도, 이벤트 페이지 하나 때문에 해킹을 당하는 수가 빈번히 있음을 주의해야 할 것이다.

2. 로깅과 모니터링
SQL 인젝션은 많은 경우 오류를 유발시키거나 동일한 페이지나 기능을 반복적으로 호출하는 형태로 공격이 이뤄진다. 따라서 유달리 500 오류가 많이 발생하거나 동일한 IP에서 동일한 페이지를 반복적으로 호출할 경우 요주의 대상으로 주의깊에 살펴야 한다.

이상현상에 대한 기준과 임계를 설정하고 해킹 시도로 판단될 시, 즉각 알림이 전송되어 바로 조사가 가능한 체계를 갖추는 것이 좋다.