현대 오토에버 클라우드 스쿨
클라우드 보안
Gom3rye
2025. 6. 12. 20:05
클라우드 보안
보안의 필요성
- 클라우드 도입은 비용 절감과 민첩성 등의 장점이 많지만 기업이 클라우드 도입을 망설이는 가장 큰 이유는 기업이 관리하는 시스템과 같은 수준의 보안을 클라우드에서도 적용할 수 있는지 확실하지 않기 때문이다.
- 클라우드 환경에서도 정보 유출과 해킹 보안 사고가 발생할 수 있다.
보안 위협과 사고 사례
- 클라우드 보안 위협
- 기업의 관리적 기술적 범위 확대
- 기존 IT 환경에서 발생했던 보안 위협이 클라우드 시스템에서도 그대로 존재하는 경우
- 관리적 보안: 보안 정책, 보안 점검, 보안 교육
- 기술적 보안: 정보 유출 방지(인프라 보호, 데이터 보호), 해킹 공격 방어(해킹 방어, 해킹 탐지)
- 물리적 보안: 시설 보안, 백업, 분산 저장
- 클라우드 서비스는 가상화 기술을 이용해서 IT 인프라를 공유하는 기술을 사용하지만 그 위에서 동작하는 미들웨어(WEB, WAS - Web Application Server)와 애플리케이션(웹 사이트, 모바일 앱 등) 들은 기존의 환경과 동일하다.
- 기업 내부에서만 사용할 때는 관리적 보안, 기술적 보안, 물리적 보안을 모든 책임을 기업이 진다.
- 관리적 보안 영역은 클라우드 서비스 사용 범위까지 넓어진다.
- 기업 내부의 보안 정책을 그대로 적용할 수 있다면 어려움이 없다.
- 클라우드 서비스 제공자가 배포하는 보안 서비스나 기능이 기업 내부와는 사뭇 다르므로 보안 정책을 완전히 그대로 적용하기는 무리가 있다.
- 기업 내부에서 사용하던 보안 솔루션(방화벽, 계정 관리 시스템 등)을 클라우드 환경에 적용할 수 없는 경우가 많다.
- 별도의 보안 솔루션이나 소프트웨어 기반의 별도 보안 솔루션으로 변경을 해야 하는 경우가 발생
- 클라우드 서비스를 위한 클라우드용 보안 관리 환경을 구성하고 기업 내부와 기업 외부에서 모두 관리할 수 있는 작업이 필요하다.
- 기술적 보안 영역에서는 인터넷 환경을 통해서 기본적인 인프라가 구축되기 때문에 정보 유출과 해킹 공격의 위험이 확대된다.
- 기술적 보안 영역은 클라우드 환경을 위한 모니터링과 최대한의 통제권 확보를 위해서 더 많은 투자가 필요하다.
- 물리적 보안 영역은 클라우드 서비스 제공자가 담당한다.
- 사용자는 클라우드 서비스가 제공하는 권역을 선택할 수는 있으나 자원의 물리적인 위치에 대해서는 알 수 없다. → 위치 투명성
- 클라우드 서비스 제공자는 사용자와 SLA(Service Level Agreement)를 통해 클라우드 서비스를 제공하는 데이터 센터의 물리적인 보안과 서비스의 가용성을 보장한다.
- 사용자는 법규나 컴플라이언스 준수를 위해서 기업의 데이터가 저장되는 물리적인 위치를 국내 또는 특정 국가에 있는 서비스 영역으로 제한할 것을 요청할 수 있다.
- 클라우드 시스템의 보안 위협
- 가상화 기술과 Multi tenancy(여러 사용자가 함께 사용하는 환경)로 인해 클라우드 환경에서 발생하는 보안 위협
- 클라우드 사용에 따른 보안 위협을 개인 스스로가 해결하기 어렵기 때문에 국제적으로 클라우드 보안 협회(CSA - Cloud Security Alliance)라는 기구가 자율적으로 구성되었고 정기적으로 클라우드에서 발생하는 보안 위협을 공유한다.
- 대표적인 보안 위협
- 불충분한 ID, 자격 증명, 엑세스 및 키 관리, 권한 있는 계정: 데이터가 손상되거나 악의적인 유출, 공급망 붕괴 등의 비즈니스 연속성 저하
- 안전하지 않은 인터페이스 및 APIs: 잘못 설계된 API는 인증되지 않은 엔드 포인트 접근, 약한 인증 절차, 과도한 권한 부여, 패치되지 않은 시스템 악용, 논리적인 설계 문제, 로깅 및 모니터링 비활성화 등으로 리소스 유출되거나 삭제 및 수정 또는 서비스 중단으로 이어질 수 있다.
- 잘못된 설정 및 부적절한 변경 제어: 데이터 유출 문제가 생긴다.
- 클라우드 보안 아키텍쳐와 전략 미흡: 클라우드 이전에 기존 IT 스택과 보안 제어 기능을 클라우드 환경에 그대로 이식하는 Lift and Shift 방법과 공동 책임 모델의 낮은 이해도로 인해 보안 이슈를 야기한다.
- 안전하지 않은 소프트웨어 개발: 소프트웨어 복잡도 증가로 인한 보안 이슈가 발생할 수 있기 때문에 안전한 키 관리 및 CI/CD를 통해서 애플리케이션을 구현해야 한다.
- 안전하지 않은 3rd party 자원: 오픈소스 보안 이슈 및 API 문제 등으로 공급망 위험이 높아질 수 있기 때문에 소프트웨어 보안 취약점 점검 및 자산 식별, 리소스 점검, SAST(정적 분석)/DAST(동적 분석) 등을 적용한다.
- 시스템 취약점: 클라우드 서비스 플랫폼의 결함으로 데이터 기밀성, 무결성, 가용성을 손상하여 잠재적인 서비스 운영에 문제가 될 수 있다.
- 우발적인 클라우드 데이터 공개: 급속한 클라우드 전환 및 확장으로 인한 보안 거버넌스 부재로 클라우드 인벤토리 및 네트워크 노출에 대한 보안 투명성 부재로 의도하지 않은 데이터 유출이 발생할 수 있다.
- 서버 리스(서버를 직접 구축하지 않는 형태) 및 컨테이너 워크로드의 잘못된 구성 및 악용: 서버 리스 모델을 사용하고자 하는 경우는 인프라에 대한 제어 및 애플리 케이션 보안 문제에 대한 완화 방안 등을 고려해야 한다.
- 서버 리스 모델을 사용하면 민첩성과 비용 절감을 도모할 수 있고 운영을 단순화한다.
- 범죄 조직/해커/APT 공격
- 클라우드 스토리지 데이터 유출
- 기업의 관리적 기술적 범위 확대
- 클라우드 보안 사고 사례
- 클라우드 서비스 제공자의 문제
- 관리 실수
- 2017년 AWS의 S3 서버(파일 서버) 관리자의 실수로 애플과 에어비앤비, 핀터레스트 등 서비스 중단
- 2018년 서울 리전 DNS 서버 설정 오류로 나이키, 넥슨, 쿠팡, 배밍 등 서비스 중단
- 시스템 오류
- 2008년 AWS사 인증 요청의 증가로 인한 과부하로 인증 서버 다운
- 2011년 AWS사 버지니아주 북부 데이터센터 데이터 복제 작업 중 용량 부족으로 전체 장애가 발생해서 EC2 사용 고객 서비스 중단 및 오류 발생
- 천재 지변
- 2011년 AWS사 일본 대지진 발생으로 해저 케이블이 손상되어서 메일 및 안드로이드 마켓 접속 불가
- 2011년 벼락으로 데이터센터 정전으로 인해 11시간 서비스 중단
- 2011년 폭풍우로 정전 사고로 EC2 장애 발생으로 서비스가 중단
- 클라우드 서비스 제공자의 해킹 사고는 외부에 쉽게 공개되지 않기 때문에 가용성 측면의 사고들이 주로 확인된다.
- 하이퍼바이저를 노린 해킹이 성공한다면 하이퍼바이저가 관리하는 서버를 이용하는 모든 사용자가 피해를 볼 수 있다. → 가장 위험한 문제
- 관리 실수
- 클라우드 서비스 사용자의 문제
- 운영자의 실수
- 2018년 인도 혼다 자동차의 클라우드 서비스 스토리지가 노출되어 Honda Connect를 내려받은 사용자 개인 정보 5만건 유출
- 2018년 유니버셜뮤직 그룹 클라우드 파트너 사의 아파치 설정 오류로 FTP 크리덴셜과 SQL 비밀번호, AWS 비밀 엑세스키 등 클라우드 시스템의 계정 유출
- 보안 설정 미흡으로 인한 해킹 공격
- 2014년에 영국 벤처 기업인 Code Spaces는 해커로부터 DDoS 공격을 받고 금전적인 요청을 받았고 AWS 관리 콘솔 비밀번호가 유출돼서 관리하던 자원을 삭제 당하고 제어권을 상실
- 일반적인 시스템의 경우 웹 사이트나 웹 애플리케이션 서버만 외부에서 접속을 허용하고 중요한 정보를 저장하는 데이터베이스나 스토리지는 내부에서 접근 제어 설정과 방화벽을 통해 외부의 직접적인 접근을 차단한다.
- 클라우드 서비스는 서비스 별로 구성 방법이 다르기 때문에 설정을 잘못하면 인터넷을 통해 데이터에 접근할 수 있게 되고 부적절한 권한 설정이나 구성으로 민감한 정보가 유출될 수 있다.
- 2014년에 영국 벤처 기업인 Code Spaces는 해커로부터 DDoS 공격을 받고 금전적인 요청을 받았고 AWS 관리 콘솔 비밀번호가 유출돼서 관리하던 자원을 삭제 당하고 제어권을 상실
- 운영자의 실수
- 책임 영역이 모호한 문제
- 2019년 캐피탈원 해킹 사고로 1억 600만 명의 고객 개인 정보가 유출되고 1억 5000만 달러의 피해가 발생했는데 범인은 AWS 엔지니어 출신으로 프로그램을 이용하지 않고 AWS 방화벽 설정 오류를 악용한 것으로 보고되었으나 AWS에서는 캐피탈원의 방화벽 설정 오류라고 설명
- 해커가 30여 개 계정을 해킹한 정황이 들어나고 AWS 클라우드 서비스 오류에 대한 논쟁 발생
- 미국 클라우드 스토리지 서비스 기업이었던 Nirvanix는 7년 이상 서비스를 제공했는데 폐업을 선언해서 고객들에게 2주 안에 고객의 시스템과 데이터를 이전하라고 통보
- 클라우드 서비스 제공자의 문제
클라우드 보안 설계
클라우드 보안의 기본 개념
- 클라우드 환경에서 생성한 자원을 활용하는 사용자 입장에서 안전하게 정보 시스템을 구축하고 IT 서비스를 제공하기 위한 방법
- 클라우드 속성과 필수 보안 요건
- 클라우드 속성
- Multi-Tenancy
- 클라우드 서비스 제공자는 다수의 클라우드 사용자에게 자원을 제공하기 위해서 물리적인 자원을 논리적으로 분할하고 격리해서 제공한다.
- 가상화를 통한 논리적 통제는 클라우드 제공자의 보안 기술과 통제 수준에 따라 중요한 데이터가 노출되거나 의도치 않게 내가 사용하는 자원에 다른 사용자의 접근을 허용하는 공유 문제를 일으킬 수 있다.
- 데이터는 암호화, 비밀키 또는 Key Pair 관리 방안과 접근 통로에 대한 모니터링 활동이 중요하다.
- ex. 이 db에 누가 언제 접근하는지 확인하는 모니터링 시스템을 꼭 만들어야 한다.
- Accessability(접근성)
- 클라우드 자원 공유를 위해서 여러 사람이 인터넷을 통해 쉽게 접근할 수 있다.
- 기존의 온프레미스 시스템에서는 내/외부에서 발생하는 접속 통제를 위해 네트워크 관점에서 경계를 정하고 방화벽과 같은 각종 보안 장치를 설치해서 자원을 통제한다.
- 클라우드 환경은 권한만 있다면 사용자가 언제 어디서든지 손 쉽게 자원을 생성하고 방화벽과 같은 보안 기술을 적용할 수 있다.
- 자원에 접근하고자 하는 주체가 누구인지 구분하고(식별) 허락된 사용자가 접근하는지를 확인해서(인증) 사용자가 수행하려는 작업의 권한을 확인하는 과정(인가)를 명확하게 해야 한다.
- 사용자가 수행하는 모든 일을 기록하고(로깅) 나중에 문제가 없는지 검토하는 과정(감사)을 포함해 클라우드 보안 설계를 수행한다. → ELK Stack이나 Fluntd 같은 도구들을 이용
- Elastic(탄력성)
- 자원들을 유연하게 변경하고 빠르게 생성하거나 삭제할 수 있는 성질
- 무분별한 자원 증설이 발생할 수 있다.
- 의도치 않은 비용 발생을 사전에 대응하기 위해서는 자원의 생성과 폐기, 변경에 대한 모니터링 및 자동화를 기반으로 한 보안 설계와 보안 점검을 고민해야 한다.
- Multi-Tenancy
- 필수 보안 요건
- 책임 추적성
- 클라우드 자원을 사용하기 전에 Identification(식별), Authentication(인증), Authorization(인가) 활동을 수행하고 자원을 사용하는 도중에는 Logging, Monitoring 활동을, 자원을 사용한 후에는 Audit(감사)을 수행해서 클라우드 보안의 특수성인 책임 추적성을 만족시켜야 한다.
- 책임 추적성은 고유하게 식별된 사용자의 행위를 기록하여 수행한 행위에 대한 책임을 부여하고 사용자 활동의 추적을 위해 감사 로그와 모니터링을 하는 활동이다.
- Indentification(식별)
- 클라우드에 접속을 요청하는 주체가 스스로를 증명하기 위해 자신이 누구인지 식별 가능한 정보를 입력하는 활동
- 사용자 ID, 로그인 ID, 계정 번호, 이메일 주소 등이 대표적
- Authentication(인증)
- 식별을 통한 사용자 정보 외에 본인을 증명할 수 있는 정보를 입력하면 이를 토대로 허가된 사용자 인지를 확인하는 신원 검증 활동
- 비밀번호, PIN, Token, 스마트 카드, 생체 인증을 입력하는 과정을 통해 로그인을 수행
- Authorization(인가)
- 인증된 사용자에게 필요한 행위를 수행할 수 있도록 권한을 부여하는 활동
- 주체는 리소스, 자원에 접근 및 필요한 행위를 수행할 수 있도록 해주는 것
- Logging
- 애플리케이션 접속/행위 로그, 데이터 엑세스 로그, 네트워크 통신 로그, 시스템 이벤트 로그, 관리자의 활동 로그 등 기록을 전자 문서로 저장하는 행위
- 이 데이터(행위 로그)는 차후에 UI 개선 등에도 사용할 수 있다.
- 데이터베이스 성능 개선에도 사용 가능하다.
- 사용자가 늘어나면 데이터베이스 분리도 생각해봐야 한다. → 성능 향상을 위해 ex. 자주 사용하는 사용자 100만명 db, 뜨문뜨문 사용하는 사용자 900만명 db
- 데이터 로그 분석 → 데이터 분석의 시발점
- Monitoring
- 시스템, 네트워크, 데이터, 사용자 등이 시스템에서 수행한 행위에 대해서 이상 징후 분석을 수행하고 실시간으로 수집된 자원의 변경이나 현황 정보를 대시보드 등으로 관리하는 활동
- 쿠버네티스에서는 프로메테우스를 많이 사용한다.
- Audit
- 감사 로그, 사용자 접속 로그 등 로그 파일이나 활동 정보를 검토해 보안 기준에 따라 계정과 권한 관리 여부를 확인하고 위험 요소를 관리할 수 있도록 보안 수준을 설정한다.
- 책임 추적성
- 클라우드 속성
일반 보안과 클라우드 보안의 차이
- 시스템 보안의 3가지 보안 요소
- 기밀성
- 중요 정보는 외부 또는 비인가자에게 공개나 노출되지 않도록 보호하는 것
- 기밀성을 향상하기 위해서 데이터 암호화 기술을 사용한다.
- 데이터 자체에 대해서는 파일 암호화, 데이터베이스 암호화 기술을 적용하고 네트워크를 통한 통신 구간의 암호화는 통신 암호화 장비나 VPN, 전용선 등의 구간 암호화를 적용한다. (가장 좋은 것은 그냥 전용선 쓰는 것)
- 무결성
- 데이터의 정확성과 일관성을 유지하고 보증하는 것
- 보안 측면에서 데이터에 대한 접근 통제와 사용자 인증 등을 포함한다.
- 데이터의 송신 측과 수신 측에서 변경 여부를 확인하기 위해 해시 알고리즘과 같은 복호화가 되지 않는 단방향 암호화를 사용한다.
- 가용성
- 외부의 공격이나 재난 등이 발생했을 때 핵심 서비스를 유지하고 피해를 빠르게 복구하여 정상 서비스를 제공하기 위한 요소
- 외부 환경에 대응하기 위해 재난 대응팀이나 업무 연속성 계획을 수립해서 운용하고 해킹 공격에 대비하기 위해 분산 처리 및 복제 등의 기술을 이용한다.
- 기밀성
- 클라우드 보안에서는 여기에 책임 추적성을 추가한다.
책임 범위
- 클라우드 서비스를 사용하는 서비스 이용자는 책임 공유 원칙을 고민해야 한다.
- 책임 공유 원칙이란 클라우드 서비스 제공자가 인프라를 관리하고 사용자는 가상의 자원을 대여해서 사용하기 때문에 클라우드 서비스에서 발생하는 보안 사고나 사건 이슈 등에 대한 책임을 클라우드 서비스 제공자와 사용자가 공유해야 한다는 것이다.
- 예를 들면 SaaS 서비스를 이용하는 클라우드 사용자는 애플리케이션 영역의 데이터, 사용자 인증 등의 보안 관리에 대해서만 채임을 담당한다.
- 사용자는 데이터 암호화 같은 보안 기술을 적용해서 데이터를 보호해주면 된다.
- 클라우드 서비스 제공자는 애플리케이션 영역 하위의 플랫폼과 인프라 영역에 대한 전반적인 보안 관리를 책임진다.
- 데이터
- 애플리케이션 — 여기까지 SaaS가 책임
- 미들웨어 — PaaS 운영체제
- 서버 — IaaS 스토리지 네트워크
보안 모델
- 성벽형/경계형과 공향형 모델
- 기존의 시스템 보안이 성벽형이나 경계형 보안 모델이라고 한다.
- 외부의 침입을 막기 위해서 방화벽을 이용해서 접속 가능한 경로를 제한하는 방식이다.
- 외부로부터 네트워크 망을 분리해서 통신을 통제하는 모델
- 클라우드 보안은 경계가 물리적 위치에 한정되지 않음
- 클라우드에서는 인바운드(데이터를 가지고 들어오는 것)와 아웃바운드(데이터를 가지고 나가는 것) 양방향에 대한 내/외부 검사를 수행하고 로깅과 모니터링 등을 구현해서 책임 추적성을 확보해야 하는데 이것이 마치 공항을 통과할 때 출입국 심사를 받는 것과 유사해서 공항형 보안 모델이라고 한다.
- 인바운드: 기본적으로 deny all
- 아웃바운드: 기본적으로 allow all
- 제로 트러스트 모델
- 클라우드 사용이 급증하면서 제시한 가이드라인
- 핵심 원칙
- 인증 체계 강화
- 마이크로 세그멘테이션: 보안 게이트웨이를 통해 보호되는 단독 네트워크 구역에 개발 자원을 배치하고 각종 접근 요청에 대한 지속적인 신뢰 검증을 수행한다.
- 소프트웨어 정의 경계: 소프트웨어 정의 경계 기법을 활용해서 네트워크를 동적으로 구성하고 정책 엔진 결정에 따라 사용자와 단말의 신뢰를 확보한 후 자원 접근을 위한 데이터 채널을 설정한다.
- Shadow IT
- 클라우드 환경의 유연성과 접근성의 장점으로 직원들은 IT 부서를 거치지 않고 클라우드 자원을 손쉽게 사용한다.
- 외부 클라우드 서버나 스토리지를 인터넷을 통해서 쉽게 접속할 수 있도록 수정이 가능함에 따라 내부 중요 정보를 클라우드 환경에 저장하거나 유출이 가능해 악의적인 내부자 정보 유출이 보안 업계의 치명적인 위협으로 다가온다.
- Shadow IT는 기업의 내부 직원들이 IT 부서에서 승인하지 않은 클라우드 애플리케이션 또는 서비스를 구입하고 활용하면서 IT 관리 부서나 관리자가 사용 실태를 파악하지 못하는 현상이다.
클라우드 전환 프로세스
사업 전략 수립 → 계획(적합한 클라우드 서비스와 CSP 선정) → 도입(아키텍처 적용) → 운영(자동화, 모니터링) → 성과
클라우드 보안 아키텍쳐 설계
보안 아키텍쳐 설계에서도 관리적 보안, 기술적 보안, 클라우드 서비스 제공자 보안으로 구분해 보안 관리가 필요한 영역을 정의하고 관리 방안을 위한 아키텍쳐를 설계한다.
관리적 보안
- 컴플라이언스, 보안 정책, 보안 조직, 보안 감사 등의 항목이 있다.
- 법, 제도의 변화에 따라 준수해야 할 보안 요건을 확인하고 관리해야 한다.
기술적 보안
- 네트워크, 서버, 콘텐츠, 애플리케이션 보안 등의 항목이 있다.
- 사용자에게 서비스를 제공하는 애플리케이션부터 통신 구간, 클라우드 서버와 스토리지 및 데이터까지 기술적으로 보호하고 관리한다.
클라우드 서비스 제공자 보안
- 하이퍼바이저와 물리 보안 영역이 있다.
보안 설계 단계
현황 분석
- 클라우드로 전환할 대상의 서비스를 선정하고 컴플라이언스에서 제공하는 요구 사항을 검토한다.
- 클라우드 역량이 부족하면 CSP에 의뢰해서 컨설팅을 통해 기업의 비즈니스 방향과 기존 시스템의 문제점을 분석해서 IT 전략을 수립한다. (MSP에 가게 되면 컨설팅을 해주시는 분들이 계신다.)
도입 대상 선정
- 클라우드 도입 목적을 정하고 클라우드 서비스 제공자가 제공하는 보안 기능과 적용 가능한 보안 솔루션에 대해 검토한다.
- 서비스 유형(IaaS, PaaS, SaaS)에 따라 업무 형태와 활용 기술들이 다르기 때문에 도입 대상의 선정은 중요한 작업이다.
위험 평가
- 기존의 클라우드에서 발생한 보안 위협들을 고려해서 보안 위험에 대한 평가를 수행한다.
- 클라우드 환경에서 시스템 아키텍쳐와 소프트웨어 아키텍쳐를 수립하고 발생 가능한 보안 위협들을 검토한다.
- 클라우드 서비스 제공자의 보안 서비스를 활용하고 부족한 통제 영역에 대해서는 향후 모니터링이나 자동화를 위한 개선이 가능한지도 검토한다.
보안 아키텍쳐 구성
- 설계서를 작성한다.
- 보안 아키텍쳐를 수립할 때는 향후 운영과 클라우드 확장에 대한 방향을 고려해야 하고 클라우드 서비스 제공자에 대한 의존도가 높아져서 특정 클라우드에 종속되는 부분(벤더 락인)도 대응 방안을 고려해야 한다.
클라우드 보안 관리를 위한 방안
- 클라우드를 이용한다고 할 때 사람들이 가장 많이 생각하는 것은 빠르고 자유롭게 시스템을 이용하는 환경이다.
- 그러나 보안 통제가 추가되면 제약 사항이 늘어남에 따라 사용자 입장에서는 온프레미스와 클라우드가 차이가 없다고 느껴진다.
- 클라우드를 사용하다 보면 더욱 다양한 클라우드 환경을 사용하고 연계하게 된다.
- 멀티 클라우드 환경이 되면 기업은 보안 관리 환경의 변화를 경험하게 되고 공통된 보안 솔루션을 여러 클라우드에 적용하는 것은 어렵다.
- 특정 클라우드에는 원하는 보안 솔루션이 없을 수도 있고 자동화 기능이 제공되지 않을 수도 있다.
- 클라우드 보안 아키텍쳐를 설계하고 SLA를 통해 서비스 제공자와 보안 책임을 공유해야 한다.
- 클라우드 확장성과 유연성을 유지하기 위해서는 보안 관리를 사용자 인증과 모니터링 중심의 공항 모델로 전환하는 것이 중요한데 이를 통해 제로 트러스트 환경으로 보안을 강화해 나가는 것이 필요하다.
- 클라우드 서비스 제공자별 보안 기능
- AWS
- Authorization
- IAM: Identity and Access Management - 사용자 계정 및 권한 관리
- AWS RAM: Resource Access Management - 멀티 계정 간 리소스 공유 기능
- AWS Organization: 계정에 대한 정책 관리, 계정 그룹 생성 및 거버넌스 중앙 통제
- Authentication
- Amazon Cognito: 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리 제공, ID/패스워드 인증 및 facebook, google과 같은 다른 서비스 계정을 통한 로그인을 지원
- AWS SSO: Single Sign-On, 여러 AWS 계정과 비즈니스 애플리케이션에 대한 SSO 엑세스를 중앙에서 관리
- Amazon Directory Service: 사용자, 그룹 및 디바이스 관리
- Protected Stores
- AWS CloudHSM: AWS 클라우드 자체 암호화 키를 손쉽게 생성 및 사용할 수 있도록 지원하는 클라우드 기반 하드웨어 보안 모듈
- AWS KMS: Key Management Service, 통합된 AWS 서비스 및 자체 애플리케이션에 걸쳐 일괄로 키를 관리하고 정책을 정의하는 기능을 제공
- AWS Secret Manager: 코드 배포 없이 보안 정보를 손쉽게 교체, 관리, 검색 기능을 제공
- AWS Certificate Manager: 공인 및 사설 SSL/TLS 인증서를 배포 및 관리하는 기능을 제공, HTTPS 서비스를 하고자 할 때 필수
- Visibility
- AWS Artifact: AWS 보안 및 규정 준수 보고서에 온디맨드 방식으로 액세스 할 수 있도록 제공
- AWS Security HUB: 우선 순위가 높은 보안 경고 및 규정 준수 상태를 확인할 수 있는 기능을 제공(대시보드, 리포트 등)
- Amazon Guard Duty: 악의적인 활동 또는 무단 동작을 지속적으로 모니터링하는 위협 탐지 서비스
- Amazon Inspector: AWS에 배포된 애플리케이션의 보안 및 규정 준수를 개선하는 자동 보안 평가 서비스, EC2 인스턴스의 취약성 평가 및 엑세스 적합성 확인
- Amazon Macie: 머신러닝을 이용해서 AWS에 저장된 민감한 데이터(개인식별정보, 지적 재산 등)를 자동으로 검색, 분류하고 보호해주는 보안 서비스
- AWS WAF: Web Application Firewall 서비스
- AWS Shield: DDoS 공격으로부터 서비스 보호
- Authorization
- AWS
클라우드 보안 서비스
공통 보안 서비스
클라우드 관리 포탈 보안
- CSP에서는 클라우드 환경에서 제공되는 모든 자원을 관리하기 위해서 클라우드 관리 포탈이 제공된다.
- 사용자는 클라우드 관리 포탈을 통해서 자원의 상태, 변경을 위한 전체 라이프사이클을 관리한다.
- 클라우드 관리 포탈을 통해서 임의의 자원이 생성되었는지 중요한 자원이 삭제되었는지 등의 모든 자원 현황을 가시화할 수 있다.
- 계정 및 접근 권한 관리
- AWS에서는 IAM이라는 서비스를 이용해서 제공한다.
- 관리 포털에 접근할 수 있는 계정, 일부 자원만 접근할 수 있는 계정, 자원의 목록만 조회하는 계정, 자원을 수정하거나 삭제까지 할 수 있는 계정, 모든 자원과 접근이 자유로운 관리자 계쩡 등을 생성하거나 삭제할 수 있고 접근할 수 있는 자원과 권한들을 정책이나 역할을 통해서 제어할 수 있다.
- API를 제공하기 때문에 자동으로 권한 관리를 하는 것이 가능하다.
- 다중 요소 인증
- 일반적인 계정 관리는 아이디와 비밀번호만으로 이루어진다.
- 클라우드 서비스에서는 계정 탈취를 방어하기 위해서 인증 방식을 강화했다.
- 기반 인증과 소유 기반의 랜덤한 토큰 방식을 추가해서 혼합형 인증 방식 모델을 제공하고 있다.
- AWS에서는 MFA(Multi Factor Authentication) 라는 이름으로 서비스가 제공된다.
- 처음에는 이메일과 비밀번호로 인증하고 개인 장비에서 토큰이 발생되며 사용자는 토큰을 입력해 로그인을 수행하게 한다.
- 지식 및 소유에 의한 인증이 결합되어 하나의 정보가 탈취되어도 관리 화면으로 로그인 할 수 없는 강력한 보안 수준을 확보할 수 있다.
로깅과 모니터링
- 현재 수행되는 상황의 로그를 실시간으로 남기고 빠르게 특이사항을 감지하는 모니터링 수행이 보안 대응에 있어서 중요하다.
- 로깅의 유형은 개별 자원에서 기본적으로 제공되는 접속 로그와 변경된 작업 이력에 대한 행위 로그, 감시 로그가 있고 사용자의 로그 등의 상세화된 로그까지 확대 적용해 보안 수준을 높일 수 있다.
- 클라우드 환경의 자원에 대한 로그 설정은 온/오프 클릭만으로 즉시 적용할 수 있고 독립적인 자원들의 로그를 수집한 후 통합 대시보드를 구성해서 실시간 모니터링을 할 수 있다. → 실제로 우리가 할 일은 on/off 설정하는 것밖에 없다.
- 클라우드 자원의 로그 설정 → 모니터링 → 알람 3단계 체계를 통해 자산 보호를 위한 모니터링 환경을 구성한다.
- AWS에서는 Cloud Watch 라는 서비스를 통해 로깅과 모니터링을 지원한다.
골드 환경(사용자 정의 환경)
- 클라우드 환경에서 필요한 자원을 활용할 때 사용자는 최초 자원의 사양과 환경값을 설정해야 한다.
- 적용해야 할 보안 서비스와 필수 라이브러리 등의 포함된 기본적인 클라우드 자원을 사전에 구축하는 것이 필요하다.
- 클라우드 제공사에서 제공하는 기본적인 이미지 셋이 아닌 일관된 보안 수준을 유지하기 위해서 사전에 미리 이미지를 만들어두거나 스크립트를 활용하는 것이 효율적이다.
- 비즈니스에 필요해서 미리 정의한 전용 이미지를 골드 환경이라고 한다.
- AWS에서는 AMI라는 서비스와 Cloudfoundation이라는 서비스로 제공된다.
- GCP에서는 Image와 Cloud Development Manager 라는 서비스로 제공
- Azure에서는 Managed Disk와 Azure Resource Manager 라는 서비스로 제공
- AWS 환경의 EC2자원으로 골드 환경을 위한 보안 요소
- EC2 접속 시에 알려지지 않은 포트로 변경 - SSH 접속할 때 22번 대신에 다른 포트를 사용
- 서비스용 포트를 알려지지 않은 포트로 변경 - http 포트를 80이 아닌 다른 포트를 사용
- Ubuntu OS 계정을 비활성화
- 서비스용 OS 계정을 생성 및 관리를 위한 권한 처리 설정
- 단순한 OS user와 password를 통한 접근이 아니라 passphrase를 통해 비대칭키로 EC2 자원에 접근하도록 설정
마켓 플레이스 활용
- 클라우드 서비스 제공자는 외부에서 개발한 솔루션을 적극적으로 받아들이고 사용자가 사용할 수 있도록 마켓 플레이스를 운영한다.
- 3rd party는 당사의 솔루션이나 서비스를 마켓 플레이스에 등록하면 사용자는 필요한 서비스를 선택적으로 활용할 수 있다.
- 필요한 보안 솔루션이나 모니터링, 위험탐지 서비스 등을 선택하면 사용자의 클라우드 환경에 자동으로 설정되어 사용만 하면 된다.
- SaaS 형태로 제공받게 된다.
- AWS와 MS의 Azure는 보안 관련 서비스인 1000여개 이상 등록되어 있는데 Google의 GCP는 아직 100개가 안된다.
네트워크 보안 서비스
외부 인터넷 환경과 직접적으로 맞닿아 있는 네트워크 영역은 보안 검토 대상에서 가장 영향이 큰 부분인데 불특정 다수에 의해서 직접적으로 접근 또는 악의적인 공격이 가능한 진입점이 될 수 있기 때문이다.
VPC
Virtual Private Cloud(가상 사설 클라우드)는 클라우드 사용자가 직접 정의하는 가상의 개인 네트워크이다.
- 다른 VPC와 논리적으로 구분되어 있기 때문에 상호 간에 호출이 차단되고 독립된 격리 네트워크망을 구성하는 것이 가능하다.
- 최초 클라우드 자원을 생성하기 전에 가상 사설 클라우드를 생성하고 비즈니스 특성에 맞는 사설 IP 주소 범위를 설정해서 커다란 네트워크를 구성하는 것이 가능하다.
- 직접 생성하지 않더라도 클라우드 자원을 생성하는 즉시 자동으로 하나의 VPC가 생성된다.
- 상호 간의 격리가 요구되는 환경이 필요한 경우 다수의 VPC를 별도로 생성하고 독립적인 클라우드 네트워크 망을 구성할 수 있다.
- 이로 인해 네트워크 간의 호출을 방지하고 보안성을 높이고 네트워크 별로 특수성이 있는 서비스를 구축할 수 있다.
- 운영, 스테이지, 테스트, 개발 환경을 독자적인 네트워크로 구성해서 사용하는 것도 가능하다.
- AWS에서는 Amazon VPC, Azure에서는 VNets, GCP에서는 Virtual Private Cloud 라는 서비스로 제공해준다.
서브넷
- VPC에서 IP 주소 범위를 설정해서 원하는 자원을 구성할 수 있는 작은 네트워크
- 서브넷을 설정하게 되면 기본적으로 같은 IP 주소 대역에서만 네트워크 통신이 가능하고 그 외의 대역은 통신이 불가능하다.
- 서브넷 재배치
- 퍼블릭 서브넷에 존재하는 자원은 인터넷 환경에서 접근할 수 있다.
- 방화벽 같은 보안 설정으로 접근을 제어할 수 있으나 보안 설정이 미흡한 상태라면 물리적으로 직접 접근이 가능한 취약점이 존재할 수 있다.
- 해당 취약점을 방어하고자 민감한 데이터나 애플리케이션 소스 코드 등이 포함된 IT 자원은 Private Subnet으로 배치해서 외부에서 접근할 수 있는 가능성을 제거한다.
- AWS나 Azure, GCP에서 서브넷 수정 기능을 제공한다.
ACL(접근 제어 목록)
방화벽에 들어가는 목록
- 외부 네트워크에서 사용자의 네트워크를 통과하는 경우 IP 주소와 포트 번호, 프로토콜 등을 확인해서 네트워크 패킷 통과를 허가하거나 거부하는 목록
- 인바운드와 아웃바운드로 구분해서 작성한다.
- 외부에서 클라우드 내부로 전달되는 것이 인바운드이고 클라우드 내부에서 외부로 전달되는 것이 아웃바운드이다.
- AWS에서는 서브넷 단위로 설정한다.
- AWS, GCP, Azure에서 제공한다.
방화벽(Firewall- Security Group)
OSI 7계층 중 3계층과 4계층에서 필터링을 수행하는 서비스
- 인바운드와 아웃바운드를 설정한다.
- VPC에서는 Load Balancer 앞에 위치한다.
- 네트워크 내에서 가장 먼저 패킷을 확인한다.
- 주의할 점
- 소스 IP, 목적지 IP, 포트는 사용하는 정보만으로 설정한다.
- CIDR의 범위는 최소한으로 설정한다.
- Any IP, Any Port, Any Protocol로 설정은 최소화하고 적절한지 정기적으로 확인한다.
네트워크 구간 암호화(TLS)
- 네트워크 구간에 전송되는 패킷 단위 데이터를 암호화하는 TLS(Transport Layer Security) 통신을 수행해야 한다.
- 클라우드 환경에서는 도메인과 TLS 인증서를 등록해서 외부와의 네트워크 통신 시 암호화 처리를 수행한다.
- 클라우드 서비스 제공자의 인증서 서비스는 무료 또는 기존의 구매 비용보다 저렴하며 한 번 인증서를 받아서 설정하면 인증서 갱신 비용이나 등록 작업이 서비스 제공자로부터 자동으로 이루어지므로 편리하다.
- AWS에서는 Certification Manager, Azure에서는 App Service Certificates, GCP에서는 SSL Certificate로 서비스를 제공한다.
VPN
- 가상의 논리적 네트워크 사설망을 구축해서 구간 암호화 통신과 외부에서의 임의적 침입을 방지하는 가상의 전용 네트워크 망
- 개별 네트워크 통신 초입 지점에 가상 사설 네트워크 게이트웨이를 두고 상대방의 네트워크 설정을 추가해서 고정된 네트워크 구간에서 안전한 사설망을 구축할 수 있다.
- AWS에서는 Site-to-Site VPN으로 Azure에서는 VPN Gateway 그리고 GCP에서는 Cloud VPN이라는 서비스로 제공한다.
전용선 구축
IDS/IPS
DDoS 방지 서비스
728x90
반응형