보안 프로세스와 문화

이번 장에서는 견고한 보안을 구축하기 위해 필요한 프로세스와 문화에 대해서 간략하게 알아보겠습니다.

경영진의 관심과 지원

제대로 된 보안을 하기 위해서 무엇보다 중요하고 필요한 것은 경영진의 관심과 지원입니다.

필자는 정보시스템감사사(CISA; Certified Information System Auditor) 라는 보안 관련 자격증을 공부한 적이 있는데  "보안 유출 사고의 원인 및 책임" 관련 문제가 있을 때 답이 헷갈릴 경우 "경영진이 책임" 이라는 답지를 선택하면 된다는 얘기를 들은적이 있습니다.

경영진은 회사 업무의 우선순위와 자원의 배분을 결정하므로 만약 경영진이 보안은 귀찮고 돈이 들고 매출에 도움이 되지 않는다는 인식을 갖고 있다면 아무리 뛰어난 실무자라도 견고한 보안을 구축할 수가 없을 것입니다. 

경영진은 이제는 보안은 비용이 아니라 비즈니스를 지키기 위한 최소한의 투자라는 인식을 갖고  장기적으로는 회사의 평판을 지키고 리스크 감소로 인해 회사 비용 절감으로 이어진다는 점을 인식해야 하고 개발자와 운영자가 보안을 신경쓸 수 있도록 우선 순위를 조정하고 지원을 해주어야 합니다.

보호 대상의 우선 순위와 중요도 식별

보안을 수행하려면 비용이 수반되므로 무엇을 누구로부터 보호할지를 식별하고 여기에 맞게 보호 절차를 수립해야 합니다. 보안도 경제적인 의사결정에 따라 보호하려는 자산의 가치보다 적은 비용을 사용해서 지켜야 하는 제약이 있습니다.

어느 조직이든 사용할 수 있는 예산의 제약이 있으므로 현실적이고 실용적인 보안을 수행하려면 보호하려는 자산이 무엇이고 어떤 가치가 있고 누구로부터 지켜야 하는지에  대해 식별하고 우선 순위를 정해야 합니다.

특히 공격자의 주요 목표는 경제적 이득이기때문에 공격자가 시스템을 공격하고 정보를 취득해서 어떻게 돈을 벌려고 할지도 생각해 보아야 합니다.

예로 현재 github 에는 언제 어떤 프로젝트에 왜 별표를 주었는지 기록을 남기는 기능이 없으므로 이런 기능을 제공해 주는 웹 서비스를 만들었다고 가정해 봅시다.  github 사용자가 어떤 프로젝트에 별을 주었는지는 해당 사용자의 profile 을 보면 다 공개되어 있고 공격자가 이 정보를 취득해도 돈 벌이로 전환하기 어려운 정보이니 이 서비스를 견고하게 하기 위해 시간과 비용을 들일 필요는 없을 것 입니다.

이는 보안에 신경쓰지 않아도 된다는 의미가 아니고 자산을 지키기 위해 자산의 가치보다 많은 비용을 투입하는건 비효율적이라는 의미입니다.

하지만 가상 화폐 거래소 서비스를 만든다면 이 서비스를 공격하여 계정을 탈취하거나 개인 정보를 도용할 수 있다면 많은 경제적 이득을 편취할 수 있으므로 보안의 우선순위를 높이고 많은 시간과 비용을 들여서 견고한 서비스가 되도록 해야 할 것입니다.

마지막으로 자산의 가치와 보호 대책은 시간이 지나면서 변화하므로 주기적으로 가치와 우선 순위를 재평가하고 보안 대책이 현재도 효과가 있는데 판단하고 조정해야 합니다.

만약 미래에 가상 화폐가 가치를 잃어서 실물 화폐와 교환이 되지 않는다면  거래소 서비스에 예전만큼 많은 비용을 들여서 보안을 적용할 필요가 없어질 수 있습니다.

과거에는 위조를 어렵게 하는게 보안 대책이었지만 (예: 출력된 문서의 위변조를 방지하기 위해 2D 바코드를 넣어서 인쇄) 복사기와 스캐너의 성능이 좋아진 지금은 적절한 보안 대책이 아닐수 있으므로 변화하는 주변 환경에 맞게 보안 대책도 갱신해 가야 합니다. 

보안에는 특권이 없다는 인식 공유

보안을 강화하면 이에 반비례해서 어쩔수 없이 불편함이 따라오기 마련이지만 보안 프로세스를 준용하므로서 얻을 수 있는 장점이 이런 불편함보다 더 크므로 보안은 예외없이 적용되어야 합니다.

만약 임원등이 이를 불편하다고 특권을 요구한다면 이는 보안의 가장 약한 고리가 되며 특히 보안 프로세스를 우회하는 특권을 요구할 정도로 권위적인 조직이라면 사회공학이나 피싱 공격에 당할 소지가 많아집니다.

통계학에는 실제로는 음성인데 양성으로 판단하는 거짓 양성(False positive; 또는 제 1종 오류)과 실제로는 양성인데 음성이라고 판단하는 거짓 음성(False Negative, 제 2종 오류)이라는 개념이 있습니다.

이해하기 쉽게 컴퓨터 보안에 대비해 보면 생체 인증 기반의 엄격한 출입 통제 시스템이 있고 정해진 위치에서 생체 정보를 입력해야 한다고 가정해 봅시다.

이때 시스템이 생체 정보를 잘못 인식해서 회사의 직원인데 직원이 아니라고 판단하는 것을 거짓 양성이라고 하고 직원의 생체 정보가 아닌데도 직원이라고 판단하는 것을 거짓 음성이라고 합니다.

둘 사이는 trade-off 가 있어서 거짓 음성이 나오지 않도록 진단률을 높이면 거짓 양성이 많아지고 반대로 거짓 양성이 나오지 않도록 진단률을 낮추면 보안이 취약해 집니다.

보안상 더 위험한 것은 거짓 음성이나 실제 임직원들이 겪게 되는 상황은 직원이 아니라고 판단하는 거짓 양성이며 만약 이때문에 불평하는 임원이 있고 회사 문화가 이를 용인한다면 진단률을 낮추거나 또는 인증 기반 출입 통제 시스템을 폐기할 수도 있습니다.

유명한 해커였던 케빈 미트닉이 주로 사용한 기법중 하나는 임원을 사칭하고 직원에게 전화를 걸어서 그동안 수집한 해당 직원의 신상 정보를 흘리며 암호를 잊었다며 전화상으로 암호를 요구하는 것이었다고 합니다.

이런 사회 공학의 가장 좋은 대응 방안은 잠시 전화를 끊고 해당 임원에게 직접 전화를 걸어 확인해 보는 것이지만 권위적인 조직일 경우 임원이 화를 낼 수 있으므로 이런 대응이 어려워집니다.

기업 보안에서 가장 취약한 부분중 하나는 인적 보안이며 이를 해결하기 위한 방법중 하나는 제대로 된 보안 프로세스를 확립하고 누구에게나 공평하게 적용하는 것입니다.

최소 권한 부여

리눅스의 root 계정은 모든 권한을 갖고 있는 슈퍼 유저이므로 모든 작업을 편리하게 할수 있지만 작은 실수로 치명적인 결과를 불러올 수 있습니다.

예로 작업자가 특정 폴더를 지우려다가 실수로 rm / -rf 등을 실행하여 시스템을 날릴 수가 있습니다.

이는 만약 일반 사용자로 실행했다면 최악의 경우라야 자기 폴더를 삭제하는 것이겠지만 root 로 실행했다면 시스템과 데이타를 날리는 치명적인 결과를 불러올 수 있습니다.

이런 사고를 방지할 수 있는 좋은 작업 습관중에 하나는 일반 사용자로 로그인하고 루트 권한이 필요한 명령어를 실행할 때만 전환하도록 최소 권한 부여 (least privileges) 정책을 만들고 실행하는 것이 좋습니다.

또한 서버에 로그인할 때 root 로 로그인하지 못하도록 차단하고 일반 사용자로 로그인한 후에 필요시에만 su 나 sudo 명령어를 사용해야 합니다.

서비스를 구동한다면 서비스의 포트를 확인해 보고 만약 1024 이후의 포트를 사용한다면 root 권한이 없어도 되므로 일반 사용자로 구동해야 합니다.

접근 통제 정책 부여

아무리 견고한 시스템을 만들었어도 접근 통제(Access Control)가 잘못되어 있으면 공격자는 이 틈을 뚫고 들어와 보안 사고를 일으킬 수 있습니다.

예로 업데이트가 제대로 설치되지 않아 취약점이 있는 데스크탑 PC가 사내에 있고 이 PC에서 리눅스 운영 서버로 ssh 연결이 가능하다면 이 약한 고리를 통해 운영 서버로 침입이 가능해집니다.

서버같이 중요 자산은 방화벽과 IP 기반의 접근 통제를 적용하고 개발자 PC 보다는 서버 작업 전용 PC 를 구비하고 여기를 통해서만 연결할 수 있도록 하는 것이 좋습니다.

Deny All, Permit Some 정책

"모든 걸 차단하고 필요한 것만 허용"하는 정책은 단순하면서 강력한 정보 보호를 위한 최선의 정책으로 white list 기반 정책이라고 합니다.

예로 ssh 서버의 방화벽 정책을 수립한다면 차단해야할 IP 를 기술하기보다는 허용할 IP 를 기술하는게 실수할 여지도 적어지고 방화벽 정책을 수정할 일이 적어지므로 운영도 도 쉬워집니다.

웹 서버의 방화벽 정책을 수립한다면 웹 서비스에 필요한 포트인 80, 443 만 허용하고 나머지 포트는 모두 차단하면 됩니다.

개발자 관점에서 예를 들어보면 웹 애플리케이션에 첨부 파일 업로드 기능이 있다면 white list 에 기반하여 허용된 파일 확장자(예: docx, xlsx 등) 만 명시적으로 업로드를 허용하고 나머지 확장자는 모두 다 차단해야 하며 관리자 기능은 접근할 수 있는 IP 를 명시적으로 설정하고 나머지는 다 차단하는 게 필요합니다.

최악의 상황을 가정하고 대비

우리가 만들고 구축하는 시스템은 최선을 다해서 구현하고 보안에도 신경을 쓴 신뢰성 있는 시스템이겠지만 이것이 끝은 아닙니다.

완벽한 보안이란 것은 있을수 없으며 아무리 공들여도 만들고 운영해도 작은 틈새를 통해 사이트가 해킹당할 수 있습니다.

서비스가 성공하고 사용자가 많아질수록 이런 일을 겪을 확률이 높아지며 이런 상황을 맞닥드렸을 경우 대응할 수 있도록 해킹에 대비한 사전 계획과 적절한 데이타와 서비스 복구 계획을 수립해야 합니다.

누구나 겪을수 있는 일이지만 계획과 준비가 있을 경우 데이타와 서비스를 신속하게 복구하고 빠르게 서비스를 개시할 수 있는 확률이 높아집니다.

또한 이런 최악의 시나리오를 가정하고 준비할 경우 전체 시스템중 보안의 약한 고리를 식별할 수 있으므로 더욱 견고한 시스템을 만들수 있습니다.

예로 웹 서버나 메일 서버같이 비무장지대(DMZ; DeMilitarized Zone)에 위치하는 서버가 해킹당했을 경우를 가정해 본다면 이들 서버에서 내부 업무용 서버로 연결할 수 없도록 네트워크를 분리하고 웹 서버 프로세스의 권한을 낮추고 접근할 수 있는 네트워크를 최소화 하는 등의 작업을 수행하게 될 것입니다.

암호화 프로토콜 필수

암호화되지 않는 프로토콜을 사용하면 전송중에 중요 정보를 누군가 가로챌 수 있으므로 암호화한 프로토콜을 사용해야 합니다.

특히 원격지 서버에 접근할 때 telnet (최근의 리눅스 배포판은 텔넷 서버가 기본 설치에서 제외됩니다.) 을 사용하면 계정과 암호가 바로 노출되므로 ssh 같이 암화화한 프로토콜을 사용해야 합니다.

웹 서비스를 제공할 경우 로그인이나 결제등 일부 서비스에 적용하기 보다는 전체 서비스에 https 를 적용하는게 고객의 정보를 보호할 수 있고 개발과 운영도 쉬우므로 추천하는 방법입니다.

중요 데이타 암호화 및 개인 정보 수집 최소화

사용자 암호처럼 중요한 데이타가 있다면 DBMS 에 원본 그대로 저장하지 말고 적절한 방법으로 암호화를 해야 합니다.

사용자 암호처럼 명확하게 암호화 대상인지 모르겠지만 유출되면 민감한 정보라 암호화를 고려하고 있다면 이 정보를 꼭 보유해야 하는지를 먼저 검토해 보십시요.

개인 정보 유출에 가장 확실한 대비책은 암호화가 아니라 불필요하거나 과다한 정보를 보유하지 않는 것입니다.

혹시 나중에 어떻게든 비즈니스에 활용할 수 있을 것 같다는 막연한 느낌에 수집하고 있다면 보유 여부를 고민해 본 후에 적절한 암호화 방법을 선택하십시요.

패치와 업데이트의 중요성 인식

아무리 견고하게 서버를 구성하고 개발과 운영을 해도 운영체제, 시스템 라이브러리, 쉘, 웹 서버 등의 인프라 SW 에서 보안 취약점이 발견된다면 모든 노력이 물거품이 될 수 있습니다.

특히 제로 데이 공격같이 취약점 패치가 나오지 않은 시점의 공격이 들어올 수 있으므로 보안 뉴스레터를 정기 구독하고 정기적으로 보안 패치와 업데이트를 적용하는 습관을 들여야 합니다.

권장하는 사이트로는 한국인터넷진흥원이 운영하는 보호나라(https://www.krcert.or.kr) 에 자주 방문해서 보안과 취약점 관련한 최신 정보를 습득하는 게 좋습니다.

가상화와 컨테이너 사용

패치와 업데이트의 중요성을 강조했지만 기업 환경에서 패치는 쉬운 일이 아닙니다. 예로 매출이 발생하는 서비스가 있는데 이게 PHP 의 최신 버전에서는 제대로 구동되지 않는다면 PHP 버전을 패치하거나 업그레이드하는 기는 어렵습니다.

이런 문제가 발생하는 것은 해당 서비스를 구동하기 위한 인프라가 격리되지 않고 운영 체제 바로 위에서 돌아가므로 운영 체제와 서비스의 결합도(coupling) 가 너무 높기 때문입니다.

높은 결합도로 인해 높은 버전의 소프트웨어를 갱신 설치하면 서비스가 돌지 않고 현재 사용하는 버전은 지원이 끝나서 취약점을 안고 서비스해야 하는 문제가 있습니다.

이렇게 높은 결합도를 낮추기 위한 좋은 방법중에 하나는 해당 서비스를 가상화하거나 또는 도커(Docker) 같은 컨테이너 기술을 사용하여 격리해서 구동하는 것입니다.

그러면 최악의 상황에서도 해당 가상 머신이나 컨테이너로 피해를 줄일 수 있으며 실제 운영 체제로 위험이 전파되는 것을 방지할 수 있습니다.

이미 인프라가 구성되어 있다면 힘들겠지만 앞으로 새로운 서비스를 구성할 경우 컨테이너 기술을 사용하여 격리하는 것은 운영의 편의성과 함께 보안도 갖출 수 있는 좋은 방법이라고 생각됩니다.

백업 - 보안의 마지막 방어선 

최근에 기승을 부리는 랜섬웨어에 대비하기 위해 여러 가지 보안 강화를 했어도 알려지지 않은 취약점이나 또는 내부자 PC 의 낮은 보안 설정등을 뚫고 랜섬웨어등에 감염되어 중요 데이타가 암호화 되거나 또는 삭제되는 사고가 발생할 수 있습니다.

이런 사고에 대비하기 위한 가장 근본적인 대처법이자 마지막 방어선은 데이타 백업이며 이제는 백업의 중요성을 느껴야 합니다.

설령 보안 침해 사고가 발생하지 않더라도 정전이나 하드웨어 고장등 예기치 않은 사고로 데이타 유실이 발생했을때에도 백업이 있다면 다시 비즈니스를 회복할 수 있습니다.

백업은 중요 작업을 하기전에 하는 것이 아니라 늘 업무의 일부가 되어 실행해야 하며 백업 결과물은 안전하게 보관해야 합니다.

또 수시로 백업 정책의 적절성 여부와 정상 수행 여부를 점검하고 주기적으로 임시 시스템에서 백업으로부터 서비스 복구를 훈련하고 이를 회사의 중요 프로세스로 정착되도록 경영진이 지원해야 합니다.