1. 개요

- 과학기술정보통신부(이하 과기부) 「클라우드컴퓨팅서비스 보안인증에 관한 고시」일부 개정안 시행 예고
> 클라우드 보안인증 등급제의 상중등급 평가기준이 반영
> 일부 개정안을 2월 6일부터 2월 26일까지 행정예고

 

2. 주요내용

- 23년 1월 클라우드 보안인증 등급제 도입
> 공공 부문의 민간 클라우드 이용 활성화를 통해 공공서비스 혁신
> 클라우드 산업 경쟁력 강화 목적

 

- 당시 등급별 보안인증 평가기준 차등화 및 하등급 우선 시행, 상중등급 보안인증 평가기준 마련 예고
> 상등급: 기존 평가기준 보완‧강화
> 중등급: 현행 수준 유지
> 하등급: 합리적 완화

 

- 과기부는 보안인증 실증사업 추진 및 민간 클라우드 이용 환경 보안성 검증 수행
> 과기부 행정내부시스템을 민간클라우드로 전환한 실증환경 구축
> 이를 대상으로 실시한 국정원의 보안진단 결과를 반영해 상중등급 평가기준 마련
> 국제표준 인증(ISO 27001(정보보안), 27017(클라우드 보안))과 FedRAMP(미국 연방정부 클라우드 보안인증) 등의 인증 평가항목을 분석하고, 추가 보완이 필요한 평가기준 도출

 

- 상등급의 경우 업무 중요도와 시스템 규모를 고려해 평가항목 4개 신설
> 외부 네트워크 차단 / 보안감사 로그 통합관리 / 계정 및 접근권한 자동화 / 보안패치 자동화 항목

 

- 중듭급의 경우 추가 항목은 없으나, 점검 내용 명확하를 위해 평가항목 일부 수정
> 시스템 격리 / 물리적 영역 분리

 

- 또한, 클라우드 환경 변화에 따를 사업자 부담 해소를 위한 제도개선 추진
> 인증평가시 의무적 취약점 점검의 경우 평가기관 점검 방식뿐만 아니라 외부 전문기관 점검 방식 등 허용
> 중복되는 평가항목 생랴그 수수로 할인 확대, 수수료 지원 강화 등

 

- 클라우드 활용이 어려운 영역을 상중하 등급으로 나누어 적합한 서비스 기준 제시
> 철저한 안전성 검증, 보안 우려 불식, 클라우드 제공 사업자 보안 수준 향상 목표
> 지속적 모니터링을 통해 개선이 필요한 부분은 보완 예정

 

3. 참고

[1] https://www.dailysecu.com/news/articleView.html?idxno=153384
[2] https://www.msit.go.kr/bbs/view.do?sCode=user&mId=113&mPid=238&pageIndex=&bbsSeqNo=94&nttSeqNo=3184054&searchOpt=ALL&searchTxt=

'클라우드 > 기본' 카테고리의 다른 글

클라우드 보안 요소  (0) 2023.02.18
클라우드 #1  (0) 2022.07.16

1. AWS Secure Token Service (STS) [1]

- 임시 자격 증명

- AWS 자격 증명을 생성할 필요 없이 AWS 리소스에 액세스할 수 있도록 권한이 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스

- 최소 15분에서 최도 36시간까지 유효

[사진 1] STS 토큰

2. STS 악용 [2]

① 공격자는 IAM 토큰 또는 자격 증명 탈취

- 악성 코드 감염, 공개적으로 노출된 자격 증명, 피싱 이메일 등으로 IAM 토큰 탈취

 

② 탈취한 인증 정보의 유효성 확인

- API 호출을 통해 탈취한 인증 정보의 유효성 확인

> API 호출이 실패할 경우 토큰의 비활성 가능성이 높음

> 토큰이 유효할 경우 여러 API를 활용해 권한과 역할을 결정

※ API: GetCallerIdentity, GetUser, ListUserPolicies, ListAttachedUserPolicies, GetPolicy, GetPolicyVersion 등

 

③ 토큰의 권한 수준에 따라 사용자 추가 생성

- AKIA 토큰이 있는 추가 IAM 사용자 생성 후 API 호출을 통해 MFA 코드 및 장치 세부 정보 추출

> 단기 ASIA 토큰 생성을 위한 AKIA 토큰, 예비용 AKIA 토큰 생성

 AKIA : AWS IAM 사용자와 연결된 장기 액세스 토큰 [3]

aws:MultiFactorAuthPresent 사용자가 MFA를 통해 자신을 인증했는지 여부 확인
aws:MultiFactorAuthAuthAge 키가 활성화된 기간을 확인

 

④ 추가한 IAM 사용자를 활용해 ASIA 토큰 생성

- API(sts:GetSessionToken) 호출 등으로 여러 ASIA 토큰 생성

※ ASIA : STS를 통한 요청에 대한 응답으로 생성된 단기 액세스 토큰 [3]

 

⑤ 데이터 탈취

- ASIA 토큰을 악용한 데이터 탈취

 

[사진 2] 과정 요약

 

3. 대응방안

- AKIA 토큰 삭제 또는 교체

- 공격으로 의심스러운 또는 확인된 사용자에게 "모두 거부" 정책 적용 및 악용 리소스 삭제

- CloudTrail 로그 기록 및 모니터링 [4]

[사진 3] CloudTrail을 사용한 추적 활동

4. 참고

[1] https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html
[2] https://redcanary.com/blog/aws-sts/
[3] https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_access-keys-audit
[4] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html
[5] https://thehackernews.com/2023/12/alert-threat-actors-can-leverage-aws.html
[6] https://www.boannews.com/media/view.asp?idx=124541&page=1&kind=1

1. 개요

- 2019.07.29 미국의 금융지주회사인 캐피탈 원(Capital One)이 해킹으로 인해 1억 6000만 명의 고객 개인정보가 유출

- 캐피탈 원은 해킹으로 인해 1억 5000만 달러의 피해가 발생 (당시 환율 기준 약 1773억 원)

- 유출된 개인정보는 2005~2019 초까지 신용카드를 신청한 고객들의 정보로 이름, 주소, 생년월일 등의 신상정보신용 점수 및 한도, 예금 잔액 등의 금융정보가 포함

- 그 외 2016~2018 중 23일간의 거래 내역, 14만명의 사회보장번호, 8만개의 계좌번호도 유출

- 캐피탈 원은 해킹 흔적 발견 직후 수사당국에 신고하였으며, FBI는 용의자로 시애틀에 위치한 IT 기업의 소프트웨어 엔지니어 페이지 톰슨을 검거

- 톰슨은 2016년 AWS에서 시스템 엔지니어로 근무한 이력이 있음

 

1.1 요약

- 공격자는 SSRF 취약점을 이용해 AWS EC2 메타데이터 서비스에 엑세스하여 AWS 액세스 키에 접근

- 대상 애플리케이션이 WAF 뒤에 위치했지만, Bypass가 사용되었거나 WAF가 공격을 차단하도록 구성되지 않았음

- 키를 이용해 공격자는 로컬 디스크에 S3 버킷을 나열 및 동기화하여 버킷에 포함된 모든 데이터에 엑세스가 가능해짐

※ EC2 (Elastic Compute Cloud): 아마존에서 크기 조정이 가능한 컴퓨팅 용량을 제공하는 웹 서비스

※ S3 (Simple Storage Service): 클라우드 공간에 데이터(파일)를 저장하고 사용자에게 제공해 주는 온라인 스토리지 웹 서비스

 S3 버킷(Bucket): S3에서 연관된 객체들(데이터들)을 그룹핑한 최상위 디렉토리

 

1.2 SSRF (Server Side Request Forgery)

- 2021에 발표된 OWASP TOP 10에 신설된 항목 

- 서버 측에서 위조된 요청을 보내도록 하여 일반적으로 사용자들이 접근할 수 없는 내부 자원에 접근하여 악성행위가 가능한 취약점

- 즉, 취약한 서버를 이용하여 공격자가 내부 서버에 원하는 요청을 전송하여 정보를 탈취하는 공격 유형

[사진 1] SSRF 동작 방식

2. 분석

2.1 SSRF를 이용한 AWS 자격 증명 탈취

- AWS에서 작동되는 EC2에서만 메타데이터 서비스(hxxp://169.254.169.254)에 엑세스가 가능함

- 일반적으로 해당 URL은 VM의 IP 주소, AWS 네트워크 내 배치, 호스트 이름 등의 정보를 HTTP API로 제공하며 AWS 클라우드 애플리케이션 개발자에게 매우 유용하게 사용됨

- 공격자는 SSRF를 통해 서버를 자신의 요청에 대한 프록시로 취급하도록 서버를 속여 내부망의 엔드포인트에 엑세스

[사진 2] SSRF

2.2 권한 상승

- 공격자는 위 SSRF 공격 결과와 AWS EC2 서버가 임시 크리덴셜이 포함된 엔드포이트에 엑세스할 수 있다는 지식을 결합하여 다음 URL에 대한 요청을 전송

hxxp://169.254.169.254/iam/security-credentials

- 엔드포인트의 반환 목록 중 “ISRM-WAF-Role”를 통해 엑세스한 서버가 캐피탈 원의 WAF일 것이라고 추측

- 공격자는 "ISRM-WAF-Role”를 이용해 SSRF 공격을 사용하였고, 엔드포인트는 자격 증명 세트를 반환

<요청>
curl hxxp://example.com/?url=hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role

<응답>
{ 
    AccessKeyId: "<액세스 키>", 
    SecretAccessKey: "<비밀 키>", 
}

- 인스턴스 메타데이터를 통해 연결된 IAM 역할에 대한 AWS 자격 정보를 요청할 때 응답은 다음과 같은 형식을 지님

[사진 3] 요청에 따른 반환 예시

2.1.1 자격 증명 추가

- 공격자는 "aws configure" 명령을 사용해 [사진 3]에서 확인된 자격 증명 데이터를 로컬 AWS CLI에 추가

- 또한, 텍스트 편집기를 이용해 [사진 3]에서 확인된 토큰을 환경변수 또는 ~/.aws/credentials 파일의 aws_session_token에 등록

[사진 4] ~/.aws/credentials 예시

2.3 S3의 데이터에 엑세스

- 자격 증명 추가 후 아래 명령으로 AWS STS를 호출해 자격 증명을 확인하여 올바르게 설정되었는지 확인

- 해당 명령은 사용자 ID, 계정 번호 및 ARN(Amazon 리소스 번호)를 출력함

- 명령: aws sts get-caller-identity –profile example

※ Linux 시스템에서 현재 사용자의 이름을 출력하는 명령어인 whoami 명령

{
    "UserId": "AROA5A6IYBDLAKYYJCQQQ:i-07160cbf7c64abcdef9",
    "Account": "0070074815830",
    "Arn": "arn:aws:sts::0070074815830:assumed-role/ISRM-WAF-Role/i-07160cbf7c64abcdef9"
}

 

- 훔친 키와 토큰으로 AWS CLI를 설정한 후 명령을 통해 계정에서 사용 가능한 S3 버킷을 나열

- 명령: aws s3 ls --profile example

- 공격자는 sync 명령으로 700개 정도의 S3 버킷의 내용을 다운로드

- 명령: aws s3 sync s3://bucket-credit-card-numbers /home/attacker/localstash/capitalone/ --profile example

 

3. 문제점

3.1 조사 중 확인된 문제점

① 사용자 데이터를 처리하는 과정에서 적절한 검증없이 서버에 입력값 전달

- 입력값에 대한 부적절한 검증으로 웹 응용 프로그램에서 SSRF 취약점이 이용됨

 

② 잘못된 구성된 역할 및 권한에 따른 불필요 권한 제공

- ISRM-WAF-Role이 필요하지 않은 상황에도 IAM 자격 증명을 반환함

 

③ 암호화 부재

- AWS S3 데이터 스토리지는 암호화되지 않음

 

④ 모니터링 부재

- IAM 및 AWS STS API 호출과 민감한 데이터 특성을 고려한 S3 읽기/쓰기에 대한 모니터링

 

3.2 보고된 Cloud 취약점

① 클라우드 설정 오류 때문에 발생하는 보안 사고는 아직도 지나치게 많은 수준

> 과도한 권한 부여, 잘못된 보안 설정 등

 

② SSRF는 Cloud 환경에 오래전부터 알려진 위협

> RSA Conference 2015에서 SSRF 취약점을 활용한 API 키 및 자격 증명 데이터 탈취 발표

 

4. 보안 권장 사항

① 각 애플리케이션, EC2 인스턴스 또는 자동 확장 그룹에 고유한 IAM의 존재 확인

> 관련 없는 애플리케이션 간 역할 공유 금지

 

② 과도한 권한 설정 금지

> 필요한 AWS 리소스에만 엑세스할 수 있도록 각 역할의 권한 설정

 

③ 접근 통제

> 허가된 IP 또는 VPC 엔드포인트에 대한 접근 통제

 

④ 모니터링

> 전사 차원의 AWS CloudTail 활성화 여부 점검 및 로그 모니터링

 

5. 참고

[1] https://www.capitalone.com/digital/facts2019/
[2] https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea
[3] https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af
[4] https://www.techtarget.com/searchsecurity/news/252467901/Capital-One-hack-highlights-SSRF-concerns-for-AWS
[5] https://www.justice.gov/usao-wdwa/press-release/file/1188626/download
[6] https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
[7] https://www.itworld.co.kr/news/129854
[8] https://it.chosun.com/site/data/html_dir/2019/07/31/2019073101186.html
[9] https://zdnet.co.kr/view/?no=20190816173209
[10] https://www.boannews.com/media/view.asp?idx=107662

1. 개요

- 클라우드에 대한 의존도가 높아질수록 보안 팀들에게는 어려워짐

- 데이터를 스스로 관리하는 것이 아닌 외부에 위치시키기 때문

- 현재 기업들은 평균 2000개의 클라우드 서비스를 사용하는 것으로 조사

- 클라우드 상에서 발생가능한 사고의 예방과 후속 대처를 모두 신경 써야할 필요

 

2. 위협

2.1 서드파티 소프트웨어와 공급망의 위험

- 서드파티란, 제3자라는 뜻으로 원천기술과 호환되는 상품을 출시하거나 해당 기술을 이용한 파생상품을 생산하는 회사를 의미

- 많은 기업들이 정보를 클라우드에 보관하며, 서드파티에게 클라우드 접근 권한을 부여함

- 기업의 IT환경에서 파트너사들은 계약을 통해 내부 네트워크와 데이터에 접근이 가능하며, 서드파티를 보안 장비에서 예외 적용할 가능성이 존재

- 공격자들은 피해 기업을 공격하는 대신 서드파티를 공격함으로써 동일한 피해를 유발할 수 있음

- 즉, 클라우드에 대한 서드파티의 관리 실수가 침해사고로 이어질 수 있음

 

2.2 랜섬웨어

- 많은 기업들이 인프라와 데이터 등을 클라우드로 옮기는 중

- 공격자들은 계속해서 새로운 랜섬웨어를 만들어내고, 클라우드 서비스를 대상으로하는 랜섬웨어를 만들기 시작

- 클라우드용 랜섬웨어와 클라우드를 협박하는 새로운 전술들도 등장

- 크게 3가지 종류로 나뉠 수 있음

① 클라우드와 연동된 파일 공유 서비스를 대상으로 한 랜섬웨어

② 클라우드 기반 이메일 서비스를 대상으로 피싱 메일 유포하여 계정 탈취 후 랜섬웨어 유포

③ 클라우드 호스팅 업체 자체를 대상으로 한 랜섬웨어

 

2.3 APT

- 클라우드는 기업의 네트워크와 맞물려 동작하기에 APT 공격 대상이 되기도함

- APT 단체 팬시베어(Fancy Bear), 코지베어(Cozy Bear), 가돌리늄(Gadolinium) 등은 이미 클라우드 인프라를 활용

- APT 단체들이 노릴 만한 것들이 점점 더 클라우드 환경에 많아지고 있음

- 클라우드 확보 후 이를 바탕으로 각종 공격을 손쉽고 효율적으로 수행하는 트렌드

 

2.4 멀티클라우드의 확산

- 클라우드 서비스를 도입할 때 여러 클라우드를 도입

- 멀티클라우드를 도입한 회사는 통계 마다 다르나 절반을 넘어선 수치를 기록

- 멀티클라우드 증식(multicloud sprawl) 문제: 클라우드 하나로도 복잡한 아키텍쳐로, 이것이 중첩되어 발생하는 일종의 복잡성 문제

- 데이터가 돌아다니고 저장되는 영역이 훨씬 많아져 추적하고 관리하는 게 힘들어지는 문제

- 또한, 클라우드마다 로깅 방식, 보안 옵션 등의 차이가 있으며, 데이터의 표준 포맷이 존재하지 않음

- 클라우드 보안의 핵심사안은 가시성으로, 멀티클라우드 환경으로 옮겨갈 경우 가시성 확보가 어려워지거나 불가능해짐

 

2.5 셰도우 데이터

- 셰도우 데이터(shadow data): 불필요하게 복제되거나 불필요한 곳에 저장된 채 관리 받지 못하고 잊혀진 데이터

- 다크 데이터(dark data) 혹은 고스트 데이터(ghost data)라고 부름

- 클라우드 환경으로 전환하면서 어떤 데이터가 어떻게 중복되거나 사라지거나 잊혀질 지 알지못함

 

2.6 클라우드 내의 과도한 권한 허용

- 클라우드의 장점 중 하나는 IT 관리자들이 사용자들에게 권한을 편리하게 부여할 수 있다는 것

- 필요에 따라 필요한 만큼의 권한을 부여해야 하지만 매번 변경하는것 또한 어려운 일

- 클라우드를 사용하려는 경우 권한에 관한 문제 해결이 무조건적으로 필요

 

2.7 휴먼에러

- 보안분야에서 휴먼에러는 이미 널리 알려진 문제

- 특히 클라우드와 관련된 보안 사고 중 가장 많은 비율을 차지

- 클라우드의 구축과 활용이 꽤나 쉽다는 사실이 상황을 악화시키는 중

- 누가 어떤 상황에서 실수할지 예측할 수 없으며, 실수가 어느정도의 파급력을 가져올지도 알 수 없음

- 보안 솔루션에 의존하지 않고 끊임없는 보안 교육의 필요성

 

 

 

[주말판] 2023년 클라우드 생태계를 위협할 7가지 치명적인 요소들

클라우드가 등장한 직후부터 ‘클라우드 보안’은 어느 조직에나 힘든 과제가 되었다. 사실 클라우드라는 것은 그 개념부터 위험하기 짝이 없다. 인터넷을 통해 제공되는 컴퓨팅 서비스들 위에

www.boannews.com

'클라우드 > 기본' 카테고리의 다른 글

클라우드 보안인증 등급제  (0) 2024.02.08
클라우드 #1  (0) 2022.07.16

1. 클라우드(Cloud)

- 서버, 스토리지, 소프트웨어 등 IT 자원을 사용자가 직접 준비하지 않고,

  제2의 전문업체로부터 인터넷을 통해 필요한 IT 자원을 빌려 사용하고, 사용량에 따라 비용을 지불

2. 특징

접근성 시간과 장소, 디바이스에 상관없이 인터넷을 통해 클라우드 서비스 이용
유연성 이용량 증가, 이용자 수 변화 등에 신속하고 유연한 대응 가능
주문형 셀프서비스 필요한 만큼만 사용
측정 가능한 서비스 사용자가 이용한 만큼 요금 부여
자원 공유 클라우드 서비스 제공자의 자원을 다수의 사용자가 공유
사용자는 자신이 사용하는 자원의 정확한 위치를 알 수 없음
확장성 필요에 따라 원하는 만큼 스케일업(처리 능력 향상), 스케일다운(처리 능력 축소) 가능
마이그레이션 품질개선, 비용절감, 신규 서비스 도입 등에 따른 마이그레이션 용이
* 마이그레이션 : 조금 더 나은 환경으로의 이주

추가적인 특징은 다음 사이트 참고.

 

클라우드 컴퓨팅의 13가지 특징 - 한국클라우드신문

[한국클라우드신문=이수현 기자] 지난 수십년간 업계는 기존 온프레미스 환경에서 클라우드 컴퓨팅 인프라로 마이그레이션해왔다. 코로나19도 이런 점진적 변화를 가속했다. 기업은 원격 작업

www.kcloudnews.co.kr

3. 분류

[캡쳐 1] https://www.whatap.io/ko/blog/9/

서비스 모델에 따른 분류
IaaS
(Infrastructure as a Service)
- 인프라(서버, 네트워크, 스토리지 등) 가상화하여 제공하고 관리
- 높은 유연성, 비용 저렴, 인프라 상위 리소스 관리 필요
PaaS
(Platform as a Service)
- 인프라 + 플랫폼(애플리케이션, 소프트웨어를 실행하기 위한 환경)
- 플랫폼 관련 이슈(라이선스, 보안 등)에 대한 서비스를 제공하므로 서비스 외 환경적이거나 관리적인 부분에 대한 고민을 덜어줌
- 특정 플랫폼 서비스에 종속될 수 있음
SaaS
(Software as a Service)
- 일반 사용자 수준의 서비스를 바로 활용가능
- 사용자는 인프라, 플랫폼상에서의 개발을 수행할 필요 없이 최종 서비스 이용
- 커스터마이징이 어렵다

IaaS -> SaaS로 갈수록 사용자가 관리해야하는 영역은 줄어들며, 지불 금액을 증가한다.

SaaS -> IaaS로 갈수록 클라우드 사용자가 관리해야하는 영역이 증가하며, 지불 금액이 감소한다.

                                      또한 사용자의 목적에따라 커스터마이징이 수월하다.

배치 모델에 따른 클라우드 유형
Public Cloud - 클라우드 제공자가 소유한 자원에 누구나, 언제, 어디서든 접속이 가능
- 개방되어 있어 상대적으로 보안수준이 저하
Private Cloud - 기업 또는 단체가 소유한 자원에 허가 받은 사용자만이 접속 가능
- On-Premis와 퍼블릭 클라우드의 중간 형태
- 사용자를 특정할 수 있어 보안에 유리
Hybrid Cloud - Public + Private
- 핵심 시스템은 Private로, 상대적으로 비핵심 시스템은 Public으로 구축

 

4. 장단점

On-Premis 환경 대비 리소스, 자원에 대한 낭비를 줄여주며, 필요에 따른 서비스 확장 및 축소가 가능하다.

또한, 가용성 측면에서 기존 환경대비 더욱 높은 가용성을 제공할 수 있다.

 

하지만, 클라우드 서비스를 이용하기 이전에 체계적이고 확실한 서비스에 대한 분석이 필요하며, 자원이 내부 네트워크에서 클라우드 환경으로 이전이 발생하기에 보안과 과련된 문제점도 존재한다. 또한, 유지보수 등 클라우드 환경과 관련된 전문 인력이 추가적으로 필요할 수도 있다.

 

5. 보안

5-1) 클라우드 보안 형상 관리(CSPM : Cloud Security Posture Management)

등장배경

- 클라우드 기반 솔루션과 서비스가 증가하면서 클라우드 인프라에 대한 보안 솔루션에 대한 수요 역시 증가할 것으로 예상
- 클라우드 구성 오류로 인한 보안 침해 사례가 증가하고 클라우드 인프라의 보안 위반 위험을 줄이기 위한 보안 도구 및 프로세스가 부족
- 클라우드 사고 99%, 설정오류로 전망

 

기능

- 컴플라이언스 또는 기업 보안 정책에 따라 클라우드 인프라의 위험 요소를 예방, 탐지, 대응 및 예측해 클라우드 위험을 지속적으로 관리하는 솔루션
- IAM부터, 스토리지, 네트워크 등 다양한 클라우드 구성 요소에 대한 보안 위협을 모니터하고 관리

 

핵심기능

- 끊임없이 변경되는 클라우드 환경에서 컴플라이언스의 지속적인 체크
- 하나 이상의 어카운트 혹은 멀티 클라우드를 통합해 한눈에 볼 수 있도록 자산 가시성 제공
- 컴플라이언스 준수 위반이 발생했을 때 신속한 자동 대응

5-2) 클라우드 워크로드 보호 플랫폼(CWPP : Cloud Workload Protection Platform)

등장배경

- 소프트웨어 개발과 효율적 운영을 위해 쿠버네티스, 컨테이너 및 PaaS, 서버리스 서비스 등이 주목을 받았고 클라우드 기술 발전에 따라 해당 환경 역시 빠르게 발전
- 하지만 컨테이너에 관련된 보안 인식은 부족한 현실이며, 이에따라 안전한 워크로드 상에서 컨테이너의 운영이 필요함

 

기능

- 온프레미스, 가상 머신(VM), 컨테이너, 서버리스 등 워크로드에 대해 가시성과 보안을 함께 제공


핵심기능

- 보안 강화 및 설정/취약점 관리
- 네트워크 방화벽, 가시성 확보 및 마이크로세그멘테이션
- 시스템 무결성 보장
- 애플리케이션 제어
- 익스플로잇 예방 및 메모리 보호
- 서버 워크로드 EDR, 행위 모니터링 및 위협 탐지·대응 
- 호스트 기반 침입 탐지 시스템
- 안티 멀웨어

5-3) 클라우드 액세스 보안 브로커 (CASB : Cloud Access Security Broker)

등장배경

- 클라우드 시대가 도래하면서 기업의 클라우드형 SaaS 서비스의 이용률도 급격히 증가
- 이러한 환경의 변화로 기존 보안제품으로는 더이상 기업을 보호할 수 없게 됐고 다음 위협에 대해 탐지가 불가능한 이슈 발생

 1) 클라우드에서 발생하는 트래픽의 모니터링 불가,

 2) 비구독 클라우드 앱에 대한 통제 불가

 3) 멀웨어‧알려지지 않은 위협에 대하여 탐지 불가 이슈 등이 발생
- 이러한 SaaS 서비스 사용에 이미 이메일, 영업/마케팅 정보, 개발 데이터 등 민감 정보가 클라우드 내에 저장되고 있음
- 2019년에 발표된 클라우드 보안 리포트(CyberSecurity INSIDERS)에 따르면 클라우드 서비스 사용에 따른 보안 문제로 64%가 ‘데이터 유출에 대한 위협’이라고 응답


기능

- 클라우드 애플리케이션을 정책에 따라 접근하도록 하는 솔루션으로 클라우드 접근 보안 중개자 역할(클라우드·온프레미스의 보안정책 시행 지점)
- 조직 전체의 클라우드 사용 가시성을 제공하고 규제 준수 요구를 보장하고 증명하며 데이터가 클라우드에 안전하게 저장되고 불법으로 유출되지 않도록 도와줌

 

핵심기능

- 실시간 데이터 유출방지(DLP) 및 장치‧데이터의 중요도 따른 엑세스 제어 등 데이터 보호
- 업로드/다운로드 데이터 감지 및 알려진/제로데이(Zero-day) 위협을 탐지하는 위협 탐지
- 사용자 인증을 위한 SSO 연동 및 위험 로그인 감시를 위한 다중 인증 지원
- 클라우드 앱 사용 관련 모니터링(Shadow IT 분석)에 따른 가시성 제공

출처 : 

 

‘클라우드 보안'의 3가지 무기 - 애플경제

최근 많은 기업이 클라우드로 이전했거나 이전 준비에 박차를 가하고 있다. 특히 클라우드는 디지털 트랜스포메이션의 핵심 전략으로 비즈니스 민첩성을 높여 시장 변화에 유연하게 대응하도

www.apple-economy.com

* 상기 5-1 ~ 5-3에 대하여 추가적인 포스트잉을 진행

5-4) CSA의 클라우드 컴퓨팅에 대한 주요 위협 보고서

- 매년 CSA(Cloud Security Alliance)에서 클라우드에서 발생할 수 있는 보안 취약점에 대한 보고서를 발표

 

Search | CSA

Search CSA resources, tools, publications and more.

cloudsecurityalliance.org

'클라우드 > 기본' 카테고리의 다른 글

클라우드 보안인증 등급제  (0) 2024.02.08
클라우드 보안 요소  (0) 2023.02.18

+ Recent posts