블로그 운영자의 개인적인 의견입니다. 팩트와 글의 내용이 다를 수 있습니다.
※ 서론
회사 내에서 나의 주요 업무 중 하나는 DBAC(DataBase Access Control)와 SAC(Server Access Control) 시스템 운영이다. DBAC는 데이터베이스접근제어, SAC는 서버접근제어로 해석되며 Server와 DB에 인가된 사용자만 접근할 수 있도록 네트워크 상에서 시스템 접근을 통제하는 시스템 접근제어 솔루션이다. Server와 DB 등의 시스템에 접근을 통제하는 이유는 시스템이 해킹당할 시 조직의 경영에 막대한 영향을 끼치기 때문이다.
시스템접근제어의 근본적인 목적은 인가자만 시스템에 접근 가능하고 비 인가자에 대해서는 차단하는 것이지만, 개인정보보호법, ISMS-P 인증 등 법적 컴플라이언스를 준수하기 위하여 많은 기업들이 시스템접근제어 솔루션을 운영하고 있다.
대표적인 예시로는 개인정보보호법, 개인정보 안전성 확보조치 기준이 있다.
https://www.law.go.kr/LSW//admRulInfoP.do?admRulSeq=2100000229672&chrClsCd=010201
개인정보의 안전성 확보조치 기준 | 국가법령정보센터 | 행정규칙
www.law.go.kr
기업에서는 서로 다른 다양한 시스템을 운영하고 있다. 수 백대에서 많게는 수 만대가 시스템들을 효율적으로 관리하기 위해서는 중앙에서 통합적으로 관리할 수 있는 솔루션이 필요하다. 시스템접근제어 솔루션은 노가다 작업으로부터 보안담당자 손목을 보호해주는 역할을 하고 있다.
1. (접근통제) 시스템 접근에 대해서 인기자&비 인가자에 대해 통제한다.
2. (접근권한의 관리) 인가자에 대해서 최소한의 접근 권한 부여하고 접근 가능 기한을 설정한다.
3. (접근기록의 보관) 시스템 접근 및 접근 후 액션에 대해서 데이터 로깅한다.
4. (접근기록의 점검) 로깅된 내용들을 토대로 해킹 및 개인정보 유출이 일어났는지 사후 검토 및 추적한다.
5. (개인정보 암호화) 네트워크 상에서 개인정보를 마스킹처리하여 개인정보 유출을 방지한다.
※ How to?
시스템접근제어 솔루션은 국내 기업이라면 대부분 국산 장비를 쓰고 있을 것이다. 대한민국은 법의 적용 범위가 *속인주의와 *속지주의가 함께하기 때문에 국내 법을 준수하기 위한 기능들이 탑재되어 있는 국산 장비를 운영을 선호한다. 국가·공공기관의 경우 솔루션에 따라 CC인증 또는 보안인증 확인서를 받은 솔루션만 도입하여 운영이 가능하다. 그렇기에 국가·공공기관은 외산 제품을 선택할 여지 조차 없을거 같다. (CC인증이나 보안인증 확인서는 국내에서 평가하는데 외산 제품이 국내 보안 인증을 받는 경우는 희박하지 않을까? 이 좁은 땅덩어리에서 굳이...?)
*속인 주의 : "로마 사람이라면 로마 법을 따라라"의 개념
*속지 주의 : "로마에 가면 로마법을 따라라"의 개념
내가 운영하는 시스템접근제어 솔루션은 DB와 Server 접근을 계정 접근 관리(IAM, Identity Access Management) 기반으로 통제한다. 사용자(Client)는 단말기(PC)에 통제 프로그램(Agent)를 설치하며, 해당 Agent를 통해서 시스템에 접근할 수 있다. Agent가 설치되어 있지 않은 Client는 모두 차단되며, Agent가 설치되어 있다고 하더라도 권한이 부여된 Client만 시스템에 접근이 가능하다.
이중화&클러스터링 따위 그리지 않은 네트워크 도식화이다. F/W은 시스템접근제어 솔루션을 바라보고 있다. Client가 시스템에 접근할 때 방화벽을 통해서 직접 접속이 불가능하며 시스템접근제어 솔루션을 통해서만 접근이 가능하다. (단, 시스템접근제어 솔루션에서 통제하지 않는 서버는 방화벽으로 통제된다.) Client가 바라본 시스템에 접근하기 위한 조건은 아래와 같다.
1. Agent 설치
2. 접근권한 신청
3. 시스템 접근
사실상 프로그램 설치하고 계정에 대한 권한 부여를 받으면 끝이다. 하지만 보안담당자 입장에서 바라본 시스템접근제어 솔루션 운영은 다양한 것들이 있다. 내가 경험해본 운영은 4가지로 나열할 수 있다.
1. 접근제어 시스템 구축 및 등록 (정책 셋팅 포함)
2. 사용자 접근권한 부여 및 접근통제 모니터링
3. 시스템 접속기록 점검
4. 그 외 (서버간의 접근제어, 클라우드 접근제어)
1. 구축 및 등록
시스템접근제어 솔루션은 등록된 시스템에 대해서만 네트워크 상에서 데이터를 처리한다. 등록되지 않은 시스템은 통제하지 않는다.
접근제어시스템에 AAA 서버와 BBB 데이터베이스를 등록한다. 등록하기 위해서는 해당 시스템의 IP와 해당 시스템에 접속하기 위한 Port가 필요하다. 대표적으로 Server와 DB에 접속하기 위한 Port는 아래와 같다.
*Server 접속: Windows(RDP/3389), Linux(SSH/22)
*DataBase 접속: MSSQL(1433), Mysql(3306), Postgre(5432)
이러한 Port는 Well-known Port 또는 Registered Port에 속하기에 Port Scanning에 취약하다. 그렇기에 시스템접근제어 솔루션은 New Dynamic Port를 생성하여 해당 Port로만 접속할 수 있도록 통제한다.
*Well-known Port : 잘 알려진 포트 / 0 ~ 1023
*Registered Port : 등록된 포트 / 1024 ~ 49151
*Dynamic Port : 동적 포트 / 49152 ~ 65535
2. 접근권한 부여 및 접근권한 모니터링
시스템 등록은 한번 구축 및 등록하면 시스템이 바뀌거나 폐기되지 않는 이상 수정해야할 일이 없다. 사용자 접근권한에 대해서만 부여하고 모니터링하면 된다. 권한부여는 웹상에서 전자결재를 통해 진행되기에 마우스 클릭 몇번이면 부여할 수 있어서 굉장히 간단하지만 바라보아야 하는 관점이 많다. 그 이유는 보안의 기본적인 룰인 '인가자에 대해서 최소한의 권한만 부여'해야 한다는 것이다. Agent가 설치되어 있다고 모든 시스템에 접근할 수 있는 것이 아니라, 신청한 최소한의 시스템에만 접근할 수 있기 떄문이다.
여기서는 보안담당자가 가장 힘들어하는 요소 중 하나, 다른 팀과의 소통이 필요하다. 소통이 어려운것이 아니다. 그들에게 왜 이렇게 해야하는 지 설득하는 일이 어려운 것이다. 대규모 인프라에서는 수 천대에서 수 만대의 서로 다른 시스템들이 운영된다. 그러한 시스템의 접근은 모두 보안팀의 통제를 받게 되는데, 보안팀에서는 서비스 운영이 주 업무가 아니기에 해당 시스템들이 무슨 역할을 하는지 알 수 없다. 즉 나는 해당 시스템이 어떤 역할을 한는지 알지 못한 상태에서 사용자에게 접근권한을 부여하는 꼴이 되는데 여기서 딜레마에 빠지게 된다. 보안담당자로서 사용자에게 '올바른 권한을 부여하였는가?' 라는 생각의 꼬리가.... 반복된다. 그들은 당장 권한이 필요하다고 요청하고 나는 힘이 없어서 권한을 줄 수 밖에 없다.
(한 회사에 오랫동안 일하면 이 문제는 해결될 것이라 생각한다.)
그리고 대부분의 사용자는 시스템접근제어 솔루션의 인프라 구조에 대해서 전혀 알지 못한다. 윈도우 서버로 예를 들겠다.
Client는 Server 접속하기 위해서는 Server에 등록된 계정이 있어야 한다. (Kerberos와 LSA 과정을 말하는 것이 아니다.) 우리가 흔히 사용하는 웹사이트 로그인만해도 회원가입을 통해 서비스에 계정을 만든다. 이러한 과정이 당연히 Server상에도 필요하다. Server에 등록된 계정이 없는데 어떻게 접속을 할 수 있겠는가? 하지만 사용자들은 Agent 계정과 Server 접속 계정이 같은 계정인줄 착각하여, 권한을 부여받았는데 왜 접속이 안되냐고 문의를 한다. 로그 상에서 확인하면 패스워드 불일치로 밖에 판단할 수 없다. 당연한 소리지만 시스템은 접속 실패 시 계정이 없다고 알려주지 않기 때문이다. 이제는 익숙해 졌지만, 익숙해진 내가 현타오지만 Server에 계정이 있는지 확인해달라고 하자. (Server 접속계정과 접근제어시스템 Agent계정이 연동된 회사는 그럴 일 없겠지만...)
3. 접속기록 점검
내가 제일 싫어하는 부분이다. 아마 대부분 싫어할 듯..? 좋아하는 사람은 주먹다짐을 신청한다.
국내 개인정보보호법에는 개인정보를 처리하고있는 개인정보처리시스템에 대하여 주기적으로 접속 및 명령어에 대하여 점검이 필요하다. 그리고 우리 회사에서 운영하는 서비스들은 ISMS(정보보호 관리체계 인증) 인증대상이다. 결함을 받지 않을려면... 필수적으로 점검해야하는데.... 쉽지 않다. 두번째로는 내부회계관리제도 중 정보기술 일반통제(ITGC, Information technology general controls) 항목이다. 벌써 지치니깐 긴 말은 생략하겠다.......
ISMS에서는 개인정보처리시스템에 대하여 개인정보처리시스템 접속 점검을 하고 있으며, ITGC에서는 비인가자 또는 비 권한 부여자에 대하여 데이터 조작어(DML, Data Manipulation Language, *Insert/Update/Delete) 명령어를 사용하였는지 점검 및 슈퍼계정에 접근기록 및 명령어 사용 기록을 점검하고 있다. 그런데 점검항목은 사실 비슷비슷하다.
로그는 허용/차단 로그만 남아 2가지 관점에서만 바라보면 된다. 실제 점검 표는 다르지만 보여줄 수 없다.
- 차단로그
1. 비인가자 차단로그 추적
2. Brute Force 시도에 대하여 점검
3. 비인가 IP대역의 접근이 있는지 점검
4. 슈퍼 계정 접근 시도에 대하여 점검
5. 업무시간 외 접근 시도가 있는지 점검
6. 비인가 계정 명령어 입력에 대하여 점검
- 허용로그
1. 비인가자에 대하여 차단되지 않고 허용된 로그가 있는지 점검
2. 일반 사용자가 슈퍼 계정으로 접근한 시도가 있는지 점검
3. 업무 외 시간에 접근한 시도가 있는지 점검 및 소명 요청
4. 일반 사용자가 DML 명령어를 사용한 기록이 있는지 점검 및 소명 요청
5. 대량의 데이터 요청 기록 점검 및 소명 요청
6. SA(Server Admin)와 DBA(DB Admin) 접속 및 명령어 사용 점검
- 기타
1. 데이터 백업 점검
2. 데이터&로그 무결성 점검
3. 업무 연속성 계획(BCP) 점검 (성능, 메모리 등)
1개의 서비스를 점검하는 것도 쉽지 않은데 대규모 서비스를 점검하면 시간이 어마무시하게 소모된다. 자동화가 매우 잘되어 있지만 사람의 손길이 필요한 부분이 아직 많다고 생각한다. (내가 다니는 회사만 그런가..?) 점검이 끝나면 사용자들의 이상행위에 대해서 소명 요청을 해야한다. 예를들어 'A라는 사용자가 B시스템에 새벽시간에 접근하여 DML 명령어를 실행했다' 라고 과정하자. 6하원칙을 토대로 업무시간에 하지 않고 새벽시간에 한 이유가 무엇인지 소명을 받아야 한다. 해킹은 해외에서 많이 시도되며 시간차로 인해 한국 시간 기준 새벽시간에 해킹 시도가 많이 일어나기 때문이다. 보안팀은 이러한 접근 기록에 대해서 소명받고 올바른 접근인지 판단해야 하며, 해킹 뿐만아니라 서비스 운영자의 개인정보 유출 관점에서도 바라보아야 한다.
4. 그 외
시스템접근제어 솔루션이 구축되었다고 해도 보안 리스크 줄어든 것일 뿐이며 보안 리스크가 0%가 되는 일은 절대 없다. 보안 리스크에 대해서 항상 고민하며 수용보다는 감소하는 방법을 채택해야 한다.
서버 간 접근제어
불과 몇년 전까지만해도 F/W를 기준으로 내부는 Trust Zone, 외부는 UnTrust Zone으로 구분하여 내부에서 일어나는 데이터 이동에 대해서는 보안이 취약했다. 그렇기에 Server Side 공격이 늘어났고 *Zero Trust라는 개념이 생겨났다. 시스템 접근제어 솔루션 또한 이러한 취약점이 적용된다.
*Zero Trust : '아무것도 신뢰할 수 없다' 라는 개념이 탑재된 보안 모델
그림을 보면 시스템접근제어 솔루션은 F/W 뒷 단에 위치해 있다. 즉 같은 Zone에 위치한 서버 간의 통신에 대해서는 통제하지 못하게 된다. 이러한 문제를 해결하기 위해 Node에 Agent를 설치하여 EndPoint간의 접근통제를 가능하게 했다.
Node에 설치된 Agent는 시스템접근제어 솔루션으로부터 정책을 부여받아, 다른 Node의 통신을 제어하게 된다. 서비스 운영에 필요한 최소한의 통신만 허용하면 된다.
하지만 이 과정은 정말 많은 리스크를 안고 가야 한다. 기본적으로 White List 정책을 수립해야 하는데 앞서 말했다 시피 보안팀에서는 해당 서비스들이 어떤 역할을 하는지 알 수 없다. 따라서 해당 서비스가 다른 Node로 부터 API를 받아오는지, 통신이 반드시 필요한지 검증할 수가 없다. 보안팀에서 할 수 있는 일은 모든 로그를 남기고, 해당 로그들을 토대로 서비스 운영팀에 해당 통신이 필요한지 재검증받는 일이다. 하지만 레거시 서비스들은 운영 담당자도 해당 서비스가 어떤 Node와 통신을 하는지 모른다. 또한 서버 간 접근을 통제하게 되면 Node 끼리 통신을 하지 못해 서비스 장애까지 발생할 수 있다. 해당 이슈를 과제로 선정했다면 기나긴 여행이 될 것이다. 접근 허용에 대해서는 누가 판단할 것이며, 앞으로 차단되는 모든 통신에 대해서는 보안팀이 R&R을 가져가야하는 상황이 된다. 보안을 강화하기 위한 활동이지만 욕받이가 되기 쉽기에 정말 많은 검증이 필요하다.
클라우드 인프라 접근제어
지금까지는 온프레미스 기반으로 모든 과정을 설명했다. 하지만 클라우드에는 AWS의 RDS(Relational Database Service) 또는 RedShift 같은 SaaS(Software as a Service)가 있다. 이러한 서비스들은 운영체제를 제공해주지 않는 상태에서 서비스를 제공해준다.
예시를 들어보자. Excel 문서를 사용할 수 있는 서비스라고 하자. Excel은 Windows라는 운영체제를 통해서 실행할 수 있다. SaaS는 Windows라는 운영체제를 제공하지 않는 상태에서 Excel만 제공하는 서비스이다.
운영체제가 없기에 Node에 Agent를 설치할 수 없다. Agent를 설치할 수 없기에 클라우드 방화벽에서 통신을 통제해야 한다. 관리 포인트가 늘어남과 동시에 클라우드 운영팀과 소통해야하는 새로운 문제가 발생한 것이다. AWS 방화벽은 SG(Security Group)라는 기능을 제공하는데 SG의 특징은 그룹안에 그룹을 생성할 수 있다는 것이다. SG를 분석하고 불필요한 통신을 제거하여 최소한의 접근만 허용해야하는 데, SG안에 SG가 있고 그 SG안에 SG가 있는 무한 딜레마에 빠지게 된다. SG관리 방법좀 알려주세요.
Garbage Log
앞서 개인정보처리시스템 등의 시스템에는 접속기록에 대해 점검하고 있다고 설명했다. 사용자가 어떤 명령어를 입력했는지 점검하고 있는데 명령어 로그를 보다보면 정말 알 수 없는 Garbage Log들이 많이 남아 있다. 특히, Session 접속만해도 발생하는 로그들이 있는데, 해당 명령어에는 DML 명령어들이 포함되어 있다. 본인들이 사용하지도 않은 명령어에 대해서 소명해달라고 요청하여 그들을 당황하게 하지말자.
서비스 운영팀에 Session 연결 후 바로 끊어달라고 요청하자. 그리고 해당 Session을 찾아서 정형쿼리로 등록해라. 그리고 점검 시 정형쿼리에 대해서는 예외처리하면 된다. (노가다 작업이다)
Procedure
Precedure은 개발자입장에서는 편리함을 제공하지만 보안담당자인 나에게는 골칫덩어리이다. 함수 안에 DML 명령어를 포함시켜서 로그 점검 시, Procedure 함수안에 많은 DML 명령어들이 남아 있어 서비스 운영팀에 소명을 요청했지만, 그 과정은 쉽지 않았다. Procedure 함수 안에 DML 명령어를 사용하지 못하도록 해야 하지만, SoftWare Life Cicle에 보안이 포함되지 않은 기업은 나와 같은 문제를 겪을 것이다. 잘 소통해보자^^
'SecOps > 1. 보안시스템 운영' 카테고리의 다른 글
| [EndPoint] DLP로부터 정보 유출 방지 (0) | 2024.09.09 |
|---|
