ELB & ASG
체인다이어그램
- 3Tier : Web > App > DB
- WEB : 클라이언트가 웹을 통해 요청 -> 80이나 443 port 허락
- SG에 80, 443 port 0.0.0.0/0 (누구나)에 허락하자고 해 둠
--> 이런 설정으로 WEB Tier에 연결되는 EC2 만듦
- EC2 만들면, i-xxxx이런 리소스 ID가 만들어지고, GW라면 igw-xxxx, SG면 sg-xxxx 이런 ID가 붙음
- APP : 이제 Web에 들어온 요청을 갖고 APP에 요청을 보냄
- 얘도 마찬가지로 여기 레이어에 허락되어있는 EC2가 존재할 것
- 80번에 0.0.0.0/0 허락한다고 해도 상관은 없음
- 그러나 일반적으로 앞단의 sg-xxxx를 허락하도록 함
--> 앞단의 SG을 통과한 애만 들어오라는 의미
- 이 레벨에서도 sg-yyyy 이런식의 리소스 ID가 만들어지게 됨
- DB : DB 인스턴스에 연결되어있는 SG에 3306(mysql)을 허락
- 마찬가지로 0.0.0.0/0 대신 sg-yyyy 사용
--> 앞단의 SG 통과한 애만 허용하겠다는 것!
- 여기도 sg-zzzz같은 리소스 ID 만들어짐
- 이런식으로 앞단의 SG를 통과한 애들만 들어올 수 있도록 하는 것이 체인다이어그램으로 설정한다고 하는 것
- ALB의 내부적 구성이 인스턴스 형태로 구성됨
- ALB의 경우에는 인스턴스이기 때문에 SG 설정 가능
- 따라서 앞에서 SG 한 번 거르고 서버 노드에 있는 곳에서도 SG 거치게 되는데 이 과정도 체인다이어그램으로 설정되는 것
- 참고로, NLB는 그렇지 않음
실습 - ELB & ASG
- 기존 NW 환경 확인
- VPC 만든 것 확인
- AMI 확인
2. 보안그룹 생성
- ALB의 SG 생성
- SGALB 인바운드 설정 - 80, 0.0.0.0/0
- SGALB 생성 확인
- APP SG 생성
- APPSG 인바운드 설정 - 80, 앞단의 sg ID 설정
- SGApp 생성
3. 대상그룹 생성 : EC2 > 대상그룹
- 인스턴스로 생성
- MyVPC 선택
- 대상그룹 생성 -> 대상그룹 껍데기만 만들고 ELB랑 연결할 것
4. ELB 생성 : EC2 > ELB
- ALB 선택
- MyALB 생성
- My VPC, 1a와 1c에 있는 Public Subnet에 할당
- 아까 생성해 둔 SGALB 보안 그룹에 할당
- 생성해 둔 대상그룹과 연결
- 요약 확인 후
- 생성 완료
5. 런치템플릿 생성 : EC2 > 시작탬플릿
- MyLT 생성
- 기존의 AMI 선택
- 인스턴스 선택, SGAPP 보안그룹 할당
- 생성 완
6. AutoScailing 그룹 생성 : EC2 > AutoScailing 그룹
- MyASG 생성
- myLT와 연결
- MyVPC, 1a와 1c의 Private Subnet 설정
- 아까 생성한 로드 밸런서에 연결
- ELB 상태확인 켜기 설정
- 초기값 = 2:2:2 로 설정
- ASG 생성 완
7. 대상그룹 상태확인
- Healthy Check
8. 확장 확인
- DNS 복사
- 연결 확인
- 확장확인을 위해 인스턴스 한 개 강제종료
- 1개만 정상처리 되어있음
- 인스턴스 하나 더 생김
- TG도 2개 정상 됨
9. 마무리
- ASG 삭제
- ALB 삭제
- TG 삭제
- 인스턴스 종료
Amazon VPC
AWS VPN(Virtual Private Network)
- Pubic Network에 제약 있을 경우 사용할 수 있는 것 중 하나가 VPN
- IGW를 거치지 않고 서비스 간 터널링을 맺어주는 것
- 터널링 : 암호화 인증 전송을 해주는 소프트웨어적인 네트워크 채널을 따로 맺는 것
- IPSec 플로토콜 : 양 네트워크 간 터널링을 맺어주는 서비스
- AWS와 온프레미스간 IPSec 기반으로 암호화 인증 및 정송을 도와주는 것이 VPN
- 내부적으로 보면 퍼블릭한 망 위에 IPSec 기반으로 터널링을 맺어주는 것이기 때문에 절대로 Public Network를 사용할 수 없는 고객사의 경우에는 Direct Connect를 사용해야 함
AWS Direct Connect
- 네트워크 전용선을 연결해 주는 것
- 1Gbps, 10Gbps,100..등 구매 요청 시 AWS 파트너사가 와서 네트워크 망 깔아 줌
- 파트너 사 : 연결 거점
- 구매 옵션에 따라 다르지만(1,10,100Gbps) 예상 가능한 안정된 성능으로 대용량의 데이터 전송 가능
AWS 네트워크 구성 예시
- VPN으로 AWS와 온프레미스 connect 가능
- Direct Connect 로 연결 가능
- 둘 다 사용 가능
- 하나(주로VPN)는 백업망으로 구성하는 것
VPC 피어링
- VPC 간에 사설 네트워크 연결
- 즉, AWS와 AWS 간의 VPC 통신
- 원래 VPC를 만드는 의미는 VPC 자체가 Private Network이기에 네트워크 격리를 통한 보안 향상 의도한 것
- 프로젝트 팀 별로 나누어서 리소스 격리를 VPC 안에 하고 싶기에 VPC를 여러개 사용함
- 그러나 팀 간에 서로의 노드에 접근해야 하는 상황 발생
- 그 때 Private하게 접근하고 싶다면 전용의 Gateway를 생성해주는 것이 VPC 피어링
VPC 피어링 제약 조건
- 전이적 peering 지원하지 않음
- 예를 들면, A-B 피어링 되어있고, A-C 피어링 되어있을 때, B-C 가 되고 싶다고 A한테 포워딩 요청하면 해주지 않는다는 것
- 즉, B와 C가 따로 피어링을 해야 서로 통신할 수 있다는 이야기
- 따라서, 많아질수록 지저분해짐
- 이를 해결하기 위해 Transit GW 사용
Transit Gateway
- 다수의 네트워크들을 허브 앤 스포크 형식으로 사설 연결
- 여기에 기능이 확장되면서 VPC 뿐만 아니라 추가적으로 VPN과 Direct Connect까지 연결 가능해짐
- 이론적으로 5000여개의 네트워크 연결 가능
VPC 엔드포인트
- 앞서 소개한 내용들은 전부 네트워크 단위의 기능들
- 여기서 말하는 VPC 엔드포인트는 EC2 인스턴스와 특정 서비스 간에 Private하게 통신할 수 있는 것
- VPC와 VPC를 사용하지 않는 선비스 간의 통신을 돕는 것
- 대표적으로 EC2와 RDS
- 이외의 서비스들은 VPC 밖, 리전 내에서 만들어짐
- 원래 NAT를 통해 IG -> 다른서비스 이런 통신을 함
- VPC 엔드포인트를 구성하게 되면 NAT나 IG 거치지 않아도 Private 통신 구성 가능
- VPC 엔드포인트가 모든 AWS 서비스를 지원하지는 않으나 확장중 + 별도의 것 있음
- Interface 유형과 GW 유형이 있는데 GW를 지원하는 것은 S3와 DDS 뿐
- 나머지 Interface 유형은 Network 카드를 꽂아서 같은 허브에 연결해 두는 것
프라이빗 노드 접근
- Bastion을 통한 프라이빗 노드 접근
- 클라이언트 --ssh--> Bastion Host(Public Subnet) --ssh--> Private Subnet
- 그래서 키페어 잘 나눠가져야 함
실습 - VPC Endpoint(S3)
- 퍼블릭노드와 프라이빗 노드 생성
- PubNode01 생성
- 새로운 키페어 생성
- VPC, 서브넷, 보안그룹 설정
- PriNode01 생성
- 같은 키 부여
- VPC, 서브넷, 보안그룹 설정
- 두 노드 생성 확인
2. Bucket 만들기
- mykpbuc0902 만들기
- 키페어 업로드
- 업로드 확인
3. AK 생성
- IAM 접근
- CLI 만들기
- AC 생성
4. 퍼블릭노드 (Bastion)로 ssh 연결
- 키페어 다운
- IP 확인
5. 프라이빗 노드에서 S3 접근
- private IP 확인
- 접근
- linux가 막아서 chmod 600 *해준 것
- 잘 들어와졌나 체크
6. VPC 엔드포인트 생성
- VPC EP 생성
- S3 GW 선택
- MyVPC 선택
- EP 생성
- PriRT 연결
- 연결 확인 가능
- 이제 S3 ls 접근되는 것 확인 가능
7. 마무리
- VPC 엔드포인트 삭제, S3 삭제, 인스턴스 종료, 엑세스키 삭제
AWS Database
데이터베이스 개요
- 의미있는 데이터들을 모아둔 것을 데이터베이스라고 함
- DBMS
- 프로그램 ==SQL문==> DBMS ==조작==> 데이터베이스
- MySQL(오라클), MariaDB(리눅스 기본), PostgreSQL, Amazon Aurora
- 데이터베이스 종류
- 관계형 데이터베이스(RDBMS) : 테이블 형태(스키마) 구조 갖는 것
- 비관계형 데이터베이스(NoSQL, Not only SQL) : 테이블 형태가 아닌 스키마
--> 키벨류스토어 데이터베이스 / 문서기반 데이터베이스 / 그래프 데이터 베이스
Amazon 대표 DB 서비스
- Amazon RDS : 관리형 서비스
- Amazon Aurora : 좀 더 확장된 성능을 제공하는 AWS 자체 DB
- Amazon DynamoDB : 관리형 서비스
관리형 VS 비관리형
- 관리형 : OS 설치 및 패치, DB 설치 및 패치, 백업, 중복배포 등 모든 것 자동화
- 비관리형 : 이 모든 것을 알아서 하는 것
- 관리자가 편한 방식은 관리형
- 그러나 가끔 OS를 건드러야만 원하는 대로 할 수 있음 그 때는 비관리형 사용해야 함
RDS 인스턴스 크기
- 표준 : db.m5,db.m4, ..
- 메모리 최적화 : db.x1e, db.x1, db.r5, db.r4, ..
- 버스트 성능 : db.t3, db.t2
실습 - Amazon RDS 생성 및 연결
참고 링크 : https://aws.amazon.com/ko/getting-started/hands-on/create-mysql-db/
- DB 인스턴스 생성 : 콘솔 > RDS > DB 생성
- MySQL 선택
- 프리티어로 진행 (알아서 선택됨)
- DB이름 및 관리자 이름 선택
- 자동선택된 것들 건들지 않기
- 스토리지 자동 조정 해제
- 연결 확인 및 퍼블릭 액세스 허용
- 3306 열어주는 보안그룹 생성
- 초기 DB 설정
- Error남 이유는?
- VPC DNS 설정 안해놔서
- 짠 잘됐지?
2. SQL 클라이언트 다운로드 설치 및 연결
- DB와 연결해서 열기
3. 간단한 SQL 실행
- 코드 작성 (DB 생성해서 Value 넣어보기)
4. DB 인스턴스 삭제
- 언제나 실습의 마무리는 삭제
키벨류 데이터베이스
- DynamoDB : 키-값 데이터 유형의 비관계형(NoSQL) 데이터베이스
- 완전 관리형 서비스(RDS보다 손이 덜 가는)
- 서버리스 : 서버를 관리할 필요가 없는 것
- DynamoDB의 테이블과 관게형 DB의 테이블은 다름
- 굉장히 Flexible
DynamoDB 기능 및 특징
- 일관된 성능 : 00ms 미만의 성능
- 무제한 처리량
- 완전 관리형
- 사례 : 수백만 사용자 및 초당 수백만 건의 요청 처리 / 모바일 게임 순위표, 장바구니 및 고객 프로필
실습 - DynamoDB
1. 테이블 생성 : 콘솔 > DynamoDB
2. 테이블에 데이터 추가
3. 테이블 쿼리
- 사진도 없고 기억도 없고..
4. 항목 삭제
그 외 AWS 데이터베이스
- DocumentDB : 문서기반 데이터베이스
- Neptune : 그래서 데이터베이스
- Timestream : 시계열 데이터베이스
- Quantum Ledger Database : 장부 데이터베이스
Amazon Route 53
Route 53 개요
- 가용성 확장성 뛰어난 DNS 서비스
- DNS : Domain Name system
- Name에 대한 IP가 필요한데 전세계 모든 것을 알 수 없기에 그 연결을 도와주는 것
- 알아서 세컨더리 서버 잡아줌 (4개까지)
- 관리형 네임 서비스
- 도메인 네임 구매도 가능 (중개해줌)
Route 53 라우팅 정책
- 원래 기본은 Name에 대해 IP 할당해주는 것
- 경우에 따라 하나의 이름에 여러개의 IP 등록해두는 경우 많음
- 따라서 클라이언트가 name에 대해 IP 요구하면 어떤 IP를 줄까 고민함
- 그에 따른 우선 순위 정하는 방법이 있음
--> 라우팅 정책
라우팅 정책
- 단순 라우팅 : 기본 라운드 로딩
- 돌아가면서 IP를 전달해 준다는 얘기
- 가중치 기반 라우팅 : 말그대로 가중치를 주는 것
- 어떤 IP는 3번 주고 어떤 IP는 한 번만 주고
- 지연시간 라우팅 : 클라이언트와 가까운 곳의 노드 제공 (지연시간 단축)
- 지리위치 라우팅 : 위치에 따라
- 미국 : 그 주에 해당하는IP
- 다중 응답 라우팅 : IP를 여러 개 올려두고 그 중 몇 개 던지는 것 클라이언트 쪽 앱에서 뭘로 연결할 지 선택하게 하는 것
- 장애 조치 라우팅 : Primary와 secondary로 나눠서 Primary에 대한 상태검사 후 IP 주고 응답 없을 시 Stand-by 하거 있던 IP 제공하는 것
- 고가용성
--> 리전 장애에 대한 대비까지 가능해지는 것
- 단점 : 중복되는 스페이스를 사용하게 되므로 비용이 더 많이들고 잉여의 리소스 만들어 둬야 함
--> 리전 장애에 반드시 대비해야하는 내용이 있을 때만 사용
AWS Lambda
Lambda 개요
- AWS 서버리스 애플리케이션
- 애플리케이션 실행을 위한 서버 인프라 생성, 관리할 필요 없이 간편하게 애플리케이션 생성 실행
- 지원 SDK : Python, Java, .NET, Node.js, Go, Ruby
- 개발자 입장에서는 굉장히 간단한 앱 실행하기 위해 EC2도 만들고, 백업과 패치, 중복 배포 이런 것들을 직접 고민을 해야하니까 번거로울 수 있음
- 이럴 때 lambda 사용
- 이벤트 트리거만 잘 걸어두면 됨
- 코드만 바로 올려주면 EC2 관련 절차를 하지 않아도 빠르게 간단한 애플리케이션을 보급할 수 있음
- 선호하는 언어로 사용 가능
Lambda 실행
- 방법에는 여러가지가 있음
- 예약을 걸수도 있음
- 호출하는 다른 애플리케이션을 사용할 수 있음
- 이벤트 트리거 : AWS 서비스에 특정 이벤트가 있을 때 그 이벤트가 있으면 미리 만들어놓은 람다를 실행하도록 트리거할 수 있는 기능이 있음
Lambda 특징
- 권한 : 실행역할, 정책
- 실행역할 : 서비스 리소스들의 역할을 자동으로 처리 실행
- 메모리 구성 : 128-10240M
- 고객이 지정하는 메모리를 기준으로해서 CPU의 크기 들어감
- 시간제한 : 1초-15분
- 실행 시에만 요금 부과
- 실행한 시간만큼 비용 지불
실습 - Lambda 실행
참고 자료 : https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/with-s3-tutorial.html
- 버킷 생성
- 하나는 소스용, 하나는 타깃
2. 정책, 역할 생성
- 역할 생성 (정책 생성하는 거 사진 까먹)
- 생성했던 정책 넣기
- 역할 만들기
3. Lambda 만들기
- 사용할 언어 선택
- 역할 연결
- lambda 틀 완성
5. 소스 업로드
- python 코드 업로드
6. 트리거 설정
- 소스용 버킷 할당
7. 파일 업로드 해서 실행해보기
- 파일 업로드
- 타깃 버킷 가보니 사이즈 재조정된 파일 확인 가능
8. 마무리
- 만든 거 전부 삭제하기
*권한 경계
관리형 정택을 사용하여 IAM 엔터티(사용자 또는 역할)에 부여할 수 있는 최대 권한 설정
권한경계와 자격 증명 기반 정택에서 허용되는 작업만 수행하도록 허용(교집합)
PBL 문제 풀이
[PBL 풀이 1]
다음과 같은 하나의 자격증명정책만 IAM 유저 user01에 부여되어 있고, S3 버킷 정책이 구성되어 있다면, user01은 어떤 작업을 할 수 있을지 정리하여 보시오.
(예: EC2 생성 및 상세내용 보기, S3 버킷 생성 및 목록 보기, S3 버킷에 객체 업로드 및 다운로드 등)
- IAM 정책
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
- S3 버킷 정책 → 버킷 찍고 들어가서 지정함 (리소스에 대해서)
"Effect": "Deny",
"Principal": "user01",
"Action": "s3:PutObject",
"Resource": "*"
- EC2 생성: 명시적 allow가 없음 → 암시적 deny
- S3 버킷 생성 및 목록보기: PutObject만 Deny → Allow
- 다운로드: GetObject, 업로드: PubObject → 업로드는 deny
→ 연결된 버킷말고 다른 버킷에선 정책 적용 안됨
“최소권한으로 정책 부여하자”
[PBL 풀이 2]
user01 IAM 유저에게 아래의 내용을 참조하여, 요구하고 있는 권한 제어를 설정하시오.
- IAM 정책으로 EC2에 대한 작업 중 EC2의 모든 작업 - 상세 내용을 보거나, 정보를 참조하는(읽는) 작업 및 EC2 생성 및 변경, 삭제의 쓰기 작업 등을 허가하도록 설정
- S3 버킷 정책을 통해 파일 업로드를 가능하게 하도록 권한 설정
- IAM 정책에 EC2에 대한 모든 권한이 허용되어 있다 하더라도, 권한 경계 정책을 통해 특정 EC2(i-xxxxxx)의 stop/start 만 허용하도록 경계 설정
IAM에서 AmazonEC2FullAccess 허용
권한 경계 → “Resource”: permission boundary 특정 ec2 i-xxxxx 만 start, stop 가능하도록
[PBL 풀이3]
아래와 같이 EC2를 통해 웹서버 구현이 되어 있을 때, EC2로 웹서버 접근을 할 수 없었다. (제대로 된 웹서비스를 제공할 수 없다.)
문제를 해결하기 위해 확인해야 할 내용들을 계획하고, 설명하시오.
빠른 문제 해결 가이드
- 보안 그룹 확인
- public ip, public subnet 배치 확인
- RT에 연결된 Internet gateway 확인
- 아파치 확인
Well Architected Framework
- 운영 우수성 원칙
- 보안 원칙
- 안정성 원칙
- 성능 효율성
- 비용 최적화
- 지속 가능성
AWS 커네이너 서비스
컨테이너
- 가상화 방식의 무겁고 느린 애플리케이션 서비스를 해결하기 위한 프로세스 격리 방안
- 애플리케이션 코드 + 런타임 + 라이브러리 + 시스텝도구 등을 하나의 인스턴스로 패키징
- 같은 운영체, 같은 하드웨어 박스에 나눠쓰는 OS에 후킹할 수 있는 애플리케이션
- 컨테이너 오케스트레이션 : 컨테이너를 자동으로 시작, 중지 및 관리
- OS 중복 안됨 -> 클라이언트가 요구 -> 컨테이너 바로 생성
- 빠르게 서비스 가능, 가벼움
ECS(Elastic Containter Service)
- 컨테이너화 된 애플리케이션의 쉬운 배포, 관리, 크기 조정에 도움을 주는 관리형 컨테이너 오케스트레이션 서비스
- ECS 시작 유형
- EC2 : EC2 기반의 컨테이너 조정, EC2 비용 지불
- Fargate : 서버리스 컨테이너 서비스
--> 인스턴스 구성 및 관리 불필요 (알아서 늘렸다 줄였다 해줌)
- ECR(Elastic Container Resistry) : 컨테이너 이미지 저장 서비스
클라우드 보안
보안의 3요소 (CIA)
- 기밀성 (Confidentiality) : 인가된 사용자에게만 허가
- 비밀스럽게 유지되며, 특정 인물만 볼 수 있는 기밀 정보
- 무결성 (Integrity) : 부적절한 정보 변경이나 삭제로부터 보호
- 가용성 (Availability) : 신뢰할 수 있는 정보의 접근과 사용
* 온프레미스 보안 vs 클라우드 보안
클라우드 : Gameday, Flexible
온프레미스 : 리소스 고정, 초기에 구매한 것으로 제한
AWS 보안 혜택
- 안전한 데이터 유지
- 규정 준수 요구 준수
- 비용 절감
- 빠르고 간편한 확장
공동책임 모델
- 고객이 같이 책임진다는 의미
- AWS 내부적으로 구성하는 것은 AWS 책임이지만, 그 위에 고객이 구성하는 부분은 고객책임이라는 것
- 고객책임(예시)
- 암호화 : 이건 고객이 설정하는 것
- Firewall : NACL이나 SG 이용해서 어떤 클라이언트에게 어떤 포트 허락할 지 설정하는 것
- IAM은 AWS 1차적 보안, 권한 제어는 고객이 하는 설정
- AWS 책임 : Infra쪽에 문제가 발생하 경우
- 즉, 고객은 보안의 요구사항에 맞춰서 알아서 잘 구성해야한다는 것
AWS 보안을 고려한 설계 접근 방식
- 요구사항 이해
- 요구사항에 맞춰 안전한 환경 구성
- 예시) S3 객체 데이터 암호화, IAM 권한 설정, 보안 그룹 설정 ...
- 자동으로 일관되게 구성하도록 설정할 수 있는 AWS 서비스가 또 있음 (Cloud Formation)
- 탬플릿 사용 강제 적용 -> Catalog
- 검증 활동 수행
- 이게 가장 중요함
- 시나리오 베이스로 잘 지켜지고 있는 지 검증할 필요 잇음
* 보안 향상 고려 사항
https://aws.amazon.com/ko/blogs/security/top-10-security-items-to-improve-in-your-aws-account/
백업 (보안사고 대비 복구)
- 백업이 왜 필요한가?
- 언제 어디서 어떤 상황이 발생할 지 모르기 때문에 손실에 대한 대비 필요
- 고객의 데이터 보호 책임 : AWS 공동 책임 모델
- 고객이 갖고 있는 고객의 데이터는 기본적으로 고객책임이다
- EC2, EBS, S3, 데이터베이스 데이터 : 자산분류, 위험 및 비용 등을 고려한 보호 방법 결정
- EC2 : AMI, EBS 스냅샷 활용
- Database
--> RDS : 자동 백업 저장(0-35일)
--> Aurora : 보존 기간 내 신속 복원 가능 (1-35일 지정 가능)
--> DynamoDB : 특정 시점 복구를 위한 자동 백업(-35일)
- S3 : 리전간 복제 고려
- 데이터 보호도 필요 : IAM 권한 설정, 암호화 옵션
- AWS Backup : Cloud Backup 솔루션
AWS 주요 보안 서비스
접근 및 권한 제어
- IAM
- 보안그룹&NACL
모니터링 및 로그 수집
- CloudWatch
- CloudTrail
AMI
- AMI Baking
- Full Baking : 고객생성 AMI
--> 구성의 요구사항 자주 변경되어 변경되어 변경 주기 짧으면 관리 번거로움, launch는 빨리 가능
- Half Baking : 일정 부분 고객 생성 AMI + 일정 부분 User Data
- Raw Baking : AWS가 제공하는 AMI + User Data(내가 원하는 내용)
- 보안규정 요구 사항에 맞는 내용으로 AMI 생성
- 민감 정보 등이 없는 지 점검
AWS 로그 수집
- 로그 수집의 기본 원칙
- 최대한 오래 많이 로그 수집이 기본
- 문제에 대한 원인 파악하여 개선 자료로 활용
- 리뷰 : CloudTrail
다양한 로그 활성화
- VPC 흐름 로그 : VPC 내 로그를 수집함
- 장애나 문제 발생 시 원인 파악, 분석 등의 용도로 활용
- Subnet, ENI 등을 대상으로 활성화 가능
- 로그 게시를 S3나 CloudWatch Logs로 선택 가능
- Account-id, src_addr, dst_addr, src_port, dst_port, packets, bytes, action(ACCEPT or REJECT)
- CloudWatch Logs
- 로그 수집 및 모니터링, 저장
--> 기존 시스템, 애플리케이션 및 사용자 지정 로그
--> 거의 실시간 모니터링 가능
- 예시 ) EC2 애플리케이션 로그, VPC 흐름로그, CloudTrail 등
- 특정 구문, 값 또는 패턴에 대한 로그 모니터링
- CloudWatch 경보와 연계하여 알림 가능
- S3 액세스 로그
- S3 버킷에 수행된 요청에 대한 상세 내용 저장
- 고객 기반 이해, 보안 및 액세스 감사 유용
- 활성화 필요
- 로그 필드 : 버킷, 버킷 소유자, 요청 시간, 원격 IP, 요청자, 작업, 객체키(객체이름),총시간(요청수신후 응답완료시간) 등
- ELB 액세스 로그 : 로드 밸런서에 전송된 요청에 대해 자세한 정보 저장
- 트래픽 패턴 분석 문제 해결 유용
- 활성화 필요
- 로그 필드 : 요청 받은 시간, 클라이언트 IP, 지연시간, 요청 경로 등
AWS SSM(Systems Manager)
- 다수의 EC2 운영 및 애플리케이션 보안 관리
- 인벤토리, 패치 관리자, 세션 관리자, 명령어 실행 등
CloudFormation(IaC : 코드형 인프라)
- 코드(탬플릿) 내용을 기반으로 AWS 인프라 자동 생성
- 일관된 AWS 인프라를 신속하게 반복 생성 가능
- 용어 : Stack
- 탬플릿 (JSON or YAML)
- 자동화 뿐 아니라 환경 버전 관리도 가능
- 클라우드 포메이션의 결과로 만들어진 리소스들에 대해서는 과금됨
실습 - CloudFormation
- CloudFormation을 이용한 간단한 애플리케이션 생성
- 스택생성
- Lab-network.yaml 업로드
- lab-network 설정
- 네트워크 생성 완
- 정보 확인 가능
- 애플리케이션 스택 생성
- app name 설정
- 생성 완
- 체크 가능
- 잘 나오는 것 확인 가능
2. 드리프트 감지
- 드리프트 감지되고 있는 것 확인
- SG 설정 변경
- 규칙 수정
- 드리프트 된 것 감지 됨
- 무슨 리소스가 드리프트 됐는 지 확인 가능
- 세부 정보 확인 가능
3. 마무리
- 스택삭제
Inspector
- 인스턴스의 워크로드를 자동으로 검색하여, 소프트웨어 취약성 등을 스캔하는 관리형 서비스
- (잠재적인) 보안 취약성 결과 보고
- Agent 기반
- CVE(Common Vulnerabilities and Exposures) 정보 기반 결과 집계
AWS Config
- 리소스 구성 변경을 지속적으로 모니터링, 변경사항 관리
- 규정 준수, 미준수 적용
- 결과를 보여주는 서비스 (Rule 기반)
*CIA
자동화(CloudForamtion), 권한 제어(IAM 정책), 감사(Cloud Trail), 가시성 환경(Config)
AWS GuardDuty
- 머신러닝 기반의 위협 탐지 서비스
- 계정 내 워크로드에 악의적인 활동을 모니터링 및 상세 보고
- CloudTrail 이벤트 로그, VPC 흐름 로그, DNS 쿼리 로그 등에서 수백억 이벤트 분석
- 탐지 분야
- 정찰 : 공격자의 정찰로 보이는 행동
--> 비정상적 API 활동, 의심스러운 로그인 시도, 포트 스캐닝, 알려진 악성 IP 포트 탐색 등
- 인스턴스 침해 : 인스턴스 침해를 나타내는 활동
--> 코인채굴활동, 백도어 명령, 의심되는 멀웨어, 비정상적 네트워크 트래픽 볼륨 등
- 계정침해 : 계정 침해를 나타내는 패턴
--> 특이한 지리적 위치나 익명으로부터 접근, CloudTrail 로깅 사용 중지, 특이 리저에서 인프라 배포 등
- 버킷 침해 : 버킷 침해를 나타내는 활동
--> 알려진 IP로부터 S3 무단 액세스, 비정상적 위치에서 S3 데이터 검색 등
CloudWatch 주요 기능
- 앞에서 지표와 경보(알람), 로그에 대해 본 적이 있음
- Event (->Event Bridge) : 이벤트 관리
- 규칙(Rule) : 이벤트 정의, 특정 대상 지정
- 대상(Target) : 이벤트 처리 서비스
--> EC2, Lambda, SNS
- 이벤트 서비스가 원래 Watch 안에 있었지만 서비스 범위가 넓어지며 EventBridge로 넘어감
- Event의 기능은 뭐가 있으면 뭘 하자 이렇게 설정할 수 있는 것
- 자동으로 후속 조치를 진행시켜주느 ㄴ것
- JSON으로 만든 규칙을 Target으로 처리하는 것
- 예시 ) Lambda에 함수 만들어 두고 어떤 이벤트가 있을 때, Lambda에 만들어 준 코드 자동으로 실행
DDoS 공격 완화
- DDoS(Distributed Denial of Service)공격 : 서비스 중단을 목적으로 대상 서버, 서비스 혹은 네트워크에 대량의 인터넷 트래픽을 시도하는 악의적인 공격
- 애플리케이션 레이어 DDoS 공격 : 완화정책을 우회하여 애플리케이션의 자원을 소모하도록 하기 위해 정상으로 보이는 요청 사용
- HTTP GET, DNS query Floods
- 상태고갈 DDoS 공격 : 방화벽, IPS, 로드 밸런서, OS 등의 시스템에 부하를 주기 위해 프로토콜 과다 사용
- TCP SYN Flood
- 규모 기반 DDoS 공격 : 네트워크의처리 가능한 규모보다 더 큰 트래픽을 발생시켜 네트워크 중단 초래
- UDP Reflection Attacks
AWS Shield
- DDoS 공격을 방어하기 위해 개발된 AWS 서비스
- AWS 서비스에 내장된 구조로 아키텍쳐의 큰 변경 없이 DDoS 완화를 빠르게 활용
- Shield Standard / Shield Advanced 로 구분
- Standard는 무료 기본
- Advanced는 1년 약정, 추가적으로 섬세한 케어 가능, 이거 쓰면 WAF 공짜
AWS WAF(Web Application Firewall)
- AWS 웹 애플리케이션 방화벽
- ALB, CloudFront, API Gateway에 적용
- WebACL을 구성하여 규칙이나 특정 패턴에 따른 허용, 거부 설정 가능
- 규칙 예시
- IP 주소, HTTP 헤더와 본문, URL 문자열
- SQL injection, XSS(Cross Site scripting)
- OWASP Top10과 CVE(Common Vulnerabilities and Exposures)관련 규칙들 자동 갱신
CloudFront
- CloudFront는 AWS의 캐싱 서비스
- 원래 S3는 서울에 있는데 고객들이 유럽 어딘가에 많이 있다고 하면 계속적으ㅏ로 유럽에서 서울에 있느 S3 데이터 요청을 많이 할 것임
- 그럼 유럽에서 서울로 S3 요청하면 시간도 오래 걸리고 다운로드 비용도 들 것임
- 그래서 유럽쪽에 까까운 곳에 캐싱되어 있는 데이터로 빠르게 액세스 할 수 있음
- AWS CDN(Contents Delivery Network) 관리형 서비스 : 컨텐트 전송 서비스
- 데이터 사용량이 많은 애플리케이션의 웹페이지 로드 속도를 높이기 위한 서버들의 네트워크
--> 서버 로드 줄이고,지연시간 단축
- Edge Location : AWS 글로벌 인프라 중에 하나
- 앞에서 DCs < AZ < Region 이런 구조를 설명 받은 적 있는데 AZ와 리전 같은 것 중 하나임
- 얘도 전세계 여기저기 있는 DC들을 말하는데 AZ에 있는 DC들과 겹치지 않음
- 왜 만들었는가 ? CloudFront를 위해서 만든 것
--> 캐싱 전용 데이터센터들
DDoS 공격 완화를 위한 대응 가이드
- 확장이 가능한 서비스 구조 : ELB + AutoScaling
- 공개적으로 노출되는 앤드포인트 노출 최소화
- 웹 애플리케이션 방화벽 사용
- 부하 상황에 대한 서비스 안정성 검증
- 서비스 동작 모니터링 및 경보 설정
- DDoS 발생 시 런북 작성
*Throttle 기능
짧은 시간에 같은 요청 많이 오면 잠시 멈추게 하는 기능
VPC 수신 라우팅
- 모든 수신 트래픽을 EC2 인스턴스의 탄력적 네트워크 인터페이스로 보내도록 VPC를 구성
- EC2 인스턴스는 모든 가상 어플라이언스를 실행할 수 있으며, 이 어플라이언스를 전달 경로에 삽입
- 예시 ) 의심스러운 트래픽을 검사하고 차단하고 네트워크 보안 도구
- VPC 수신 라우팅은 인터넷 게이트웨이와 가상 프라이빗 게이트웨이를 지원
AWS Gateway Load Balancer
- 파트너 어플라이언스를 위한 간편한 배포
- 확장성과 가용성
- 기존 VPC Ingress 라우팅은 확장성, 가용성, 운여의 오버헤드
- 타사 가상 어플라이언스 지원 : 방화벽, 침입 감지 및 방지
- 구현
- AWS Marketplace에서 파트너의 가상 어플라이언스 소프트웨어 찾기
- VPC에서 어플라이언스 인스턴스 시작
- 어플라이언스 인스턴스로 GWLB 및 대상 그룹 생성
- 트래픽을 검사해야 하는 GWLB 엔드포인트 생성
- GWLB 엔드포인트를 다음 홉(next-hop)으로 지정하도록 라우팅 테이블 업데이트
실습 - 인스턴스 생성 및 연결(SSM)
- 역할 생성
- SSM Manager Instance 뭐시기 선택
- ssm_instance 생성 : 고급세부정보 >> IAM 인스턴스 프로파일
- SSM으로 할건데 EC2에 Agent가 올라가야하는데 우리가 선택하는 Amazon Linux는 Agent에 설치가 되어져 있음
--> SSM과 EC2가 interaction 하는 중이기 때무네 Role이 필요함
2. EC2 인스턴스 생성
- 네트워크 설정
- 보안 그룹 새로 생성 : 인바운드 롤 항목 삭제
3. SSM Session Manager 연결
- EC2 선택 후 연결 > session manager 로 연결 or Systems Manager > session manager 로 연결
- 성공적
실습 - CloudTrail & CloudWatch
CloudTrail
- 이벤트 로그 확인 : CloudTrail은 최근 90일꺼까지밖에 못 봄
- 이렇게 세부 정보 확인 가능
- 추적 생성
- 짠..S3 버킷 만들어짐
2. 추적 활성화
- 요기 이렇게 S3에 따로 막 저장 됨
3. 마무리
- 추적 삭제, S3버킷 및 객체 삭제
CloudWatch : 지표, 경보
- 지표 확인
- 여기 들어가
- 내가 아까 생성한 EC2 인스턴스 확인 가능
- 하나 선책하면 이렇게 그래프로도 보임
2. 경보 설정
- 지표 설정
- 조건 설정
- 경보 설정(SNS)
3. 마무리
- 알람 삭제, SNS Topic 삭제
PBL Review
PBL 4
관리작업의 부담을 줄일 수 있도록 관리형 서비스를 이용하여, 재설계하시오.
-> RDS(Private Subnet), NAT Gateway (Public Subnet) 사용 권장
PBL 5
다음의 아키텍처를 관찰하여, 결합 해제가 가능한 부분이 있는지 생각해보고, 재설계하시오.
-> 한쪽이 문제가 있을 경우, 다른 쪽에 영향을 주지 않도록 3Tier 구조로 모듈화 (Web / App / RDS)
PBL 6
다음의 아키텍처를 관찰하여, 고가용성을 고려한 안전하고 유연한 애플리케이션 실행을 도울 수 있는 개선부분을 생각해 보고, 재설계하시오.
-> 또 다른 가용 영역에 중복배포 / 노드 앞단에 ALB 두고, 서비스 분산 요청 → 고가용성 / RDS → Secondary DB
'SK 쉴더스 루키즈' 카테고리의 다른 글
| 클라우드기반 취약점 진단 및 대응 실무 (0) | 2024.08.10 |
|---|---|
| 클라우드기반 시스템 운영/구축 실무 (0) | 2024.08.10 |
| 클라우드 보안(1) (0) | 2024.08.10 |
| 애플리케이션 보안 (0) | 2024.08.10 |
| 네트워크 보안 (0) | 2024.08.09 |
