가상화: 프로그램을 이용해서 pc와 같은 소프트웨어적으로 활용하는 것.
*하드웨어를 소프트웨어적으로 표현한 것.
- 파일 형태로 저장 > 읽히고, 실행 되는것.
- 장점: 파일이 있기 때문에 쉽게 복사 이동 가능
- 가상화로 구축된 서버는 파일로 복원이 가능함.
- 하드웨어자체가 가상화를 거치게 되면 이동하는 것이 가능
- 똑같이 구성되어있는 하드웨어를 복사가 가능.
클라우드: 발달된 가상화기술 > 네트워크를 통해서 IT자산을 빌려쓰는 것
- 필요에 따라 소프트웨어가 될수있고, 인프라가 될수도 있고...
분류 기준
- Iaas : 인프라 > 네트워킹 기능, 컴퓨터 및 데이터 스토리지 공간
대표적으로 EC2
- Paas : 플랫폼
- Saas : 소프트웨어
>> 플랫폼과 소프트웨어의 종류에 따라서 분화가 됨. ex)kubernates 같은 클러스터링을 구성 >
클라우드 종류
- AWS
- GCP
- Azure
- naver
- 알리바바
컴퓨팅 파워, 스토리지, db와 같은 기술 서비스에 액세스 할 수 있음
이점: 민첩성, 탄력성, 비용절감
클라우드 컴퓨팅의 이점
- 민첩성: 필요에 따라서 리소스를 빠르게 구동할 수 있다. > 고객 경험과 비즈니스 혁신
- 탄력성: 용량을 유연하게 가져갈 수 있다. > 실제 필요한 만큼의 리소스를 확장하거나 축소해서 용량을 늘리거나 줄임
- 비용 절감: 가변 비용으로 전환하고, 사용한 만큼만 IT비용을 지불
- 전세계 배포
컨테이너 기술
- Docker, EKS
- 서로 격리시켜서 OS를 이용
클러스터링 기술
- 하나의 논리적인 서버로 묶어주는 것
- Kubernates
- 멀티 노드 환경에 배포 실행
ex) 블록체인 어플리케이션 배포 실행 > 블록체인 네트워크가 있어야됨. > AWS에서 제공받는 것.
접근 여부에 따라
public cloud : 누구나
private cloud : OpenShift(클라우드 서비스 제공)
hybride cloud
t2 micro
AWS 서비스(제품)
- Amazon ==> 기본 빌딩 충족 => EC2, S3, RDS
- AWS ==> 특별한 작업, 데이터 처리, 서버리스 컴퓨팅, 데이터 분석 등과 같이 특화된 작업을 위한 솔루션
=> Lamda, Glue, Step Functions
공동책임모델
- 클라우드에서 발생하는 보안 책임
고객 책임: 인프라 구동, 운영체제, 소프트웨어 업데이트, 보안 패치, 보안 설정 (데이터에 대한 관리)
AWS 글로벌 인프라
- 32개의 지리적 리전, 가용영역 운영
- 리전: 데이터 센터의 묶음, 최소 3개 이상의 AZ로 구성되면 리전이 됨.
- 가용영역 (AZ, Abailablity): 물리적으로 떨어져있음 독립적으로 돌아가고 짧은시간으로 네트워크 연결
하나 이상의 데이터 센터로 구성 (가용성, 내결합성 및 확작성)
모든 AZ는 서로 100km(60마일) 이내의 거리에 위치
로컬 영역
- 지연 시간에 민감한 애플리케이션을 실행할 수 있도록 하기 위함
- 지연 시간에 민감한 앱을 실행 할 수 있는 aws 리전의 확장
aws wavelength
- 모바일 디바이스 및 최종 사용자에 특화된 서비스
- 지연시간을 최소화 함
aws 프리티어
- aws 계정 생성시 프리티어 자격 부여
- 해당 사용 시점부터 기간까지만 무료로 사용
- 무료평가판, 12개월 무료, 언제나 무료
* 요금제
AWS IAM(Identity and Access Management)
- AWS 서비스 및 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스
- 사용자( user ), 사용자 그룹(user group), 역할(role), 정책(policy)
- 리전에 속해있지 않고, 글로벌 서비스
- 계정을 액세스권한을 부여하고 리전에 상관없이 동일하
*보안 강화를 위한 IAM 보안 모범 사례 숙지
- 루트 계정(AWS회원 가입시 만들어지는 계정)은 최초 사용자 계정 생성 이후 가능하면 사용하지 말 것.
- 사용자는 필요한 최소한의 권한만 부여할 것 => 최소권한의 원칙
- 루트 계정과 개별 사용자 계정에 강력한 암호 정책과 멀티팩터 인증(MFA) 적용
접근제어 3단계
식별 - 인증 - 인가
인증
- Type1 - 지식기반 >> 비밀번호, 패스워드, ....
- Type2 - 소유기반 >> 공인인증서, 민증, 스마트폰, ... .
- Type3 - 특징기반 >> 필기체서명, 홍채, 정맥, 성문, 지문, ...
>> 타입2와 타입3 으로 사용할 경우 채널이 분리되서 공격이 어려움.
=> 2가지를 혼용 => 2-factor인증
=> 2rkwl dltkddmf ghsdyd => 멀티팩터 인증
인가
화면에서의 접근 통제
- 프리젠테이션 레이어 액세스 컨트롤 : 권한 있는 사용자에게 적절한 기능 버튼과 메뉴, 링크를 제공
- 비즈니스 레이어 액세스 컨트롤 : 권한 유무를 확인, 해당 사이트를 스캐닝해서 url 도출해서 패턴확인
- 데이터 레이어 액세스 컨트롤 (중요) : 접근통제가 되지 않음
식별정보
- html 태그에서 id
- 인증과 식별은 함께 이루어져야 한다.
*aws에서는 식별정보를 제시하고 해당하는 식별정보가 인증정보를 따로
사용자 ( user )
- AWS의 기능과 자원을 이용하는 객체
- 사람 또는 응용 프로그램
사용자를 식별하는 방법
- 사용자 생성 시 지정한 이름
- 사용자의 고유 식별자
- ARN( Amazon Resource Name) => arn:aws:service:region:account:-id:resource 형식
- arn : 모든 arn의 시작 부분
- aws : aws를 나타내는 고정 값
- service : 리소스를 제공하는 aws 서비스
- region : 리소스가 위치한 AWS 지역
- account-id : AWS의 계정 ID
- resource : 서비스별로 리소스를 고유하게 식별하는 정보
사용자의 자격증명 방법
- aws management console 암호 >> 사람이 AWS 서비스를 사용하기 위해서 로그인할 때 사용
- access 키 = Access Key ID + Secret Access Key >> 프로그램 방식으로 호출할 때 사용
- SSH 키 >> AWS에서 생성한 EC2 인스턴스(가상머신)로 접속할 때 사용
https://signin.aws.amazon.com/signin
iam사용자
- 한 개의 루트에 여러 사용자
- 사용자를 리전별로 배포 시켜놓은 것
사용자 > 자기계정 > 권한 >
콘솔암호 > p_______
*사용자는 새 암호를 생성해야 하는
- 사용 주체만 패스워드를 알고있다고 보장하도록
user생성시에 권한을 부여하지 않아서 대시보드에 내용이 출력되지 않음
생성한 user > arn 숫자는 사용자 고유 식별자
***꼭 필요한 만큼의 권한만 부여해야함
사용자 그룹 ( user group )
- 여러 사용자에게 공통으로 권한을 부여하기 위해서 만든 개념
- 일괄된 처리
권한 ( permission )
- AWS의 서비스나 자원에 어떤 작업을 할 수 있는지 여부를 명시한 규칙
*권한은 정책을 통해서 부여한다.
정책 ( policy )
- 자격 증명이나 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체
- 권한의 모음으로 사용자, 사용자 그룹, 역할에 적용이 가능
- 사용자, 사용자 그룹, 역할에 권한을 직접 적용할 수 없고, 정책을 생성한 후에 적용해야 함
자격 증명 기반 정책
- IAM 사용자, 그룹, 또는 역할에 연결되는 정책으로 자격 증명이 수행할 수 있는 작업(권한)을 지정
- 관리형 정책
> 다수의 사용자들이 쓸 수 있게 사용자, 사용자 그룹, 역할 독립적으로 연결할 수 있는 정책
- 인라인 정책
> 단일 사용자들의 사용자, 사용자 그룹, 역할에 직접 추가하는 정책
리소스 기반 정책
- S3(파일 저장소) 버킷과 같은 리소스에 연결하는 정책으로 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 권한을 부여하고 이러한 권한이 적용되는 조건을 정의
- 리소스 기반 정책은 인라인 정책이며, 관리형은 리소스 정책이 없다. (미리 정해놓을 수 없고, 각각의 리소스를 그때 그때 정해야 함)
권한 경계
- 관리형 정책을 사용해서 자격증명 기반 정책이 IAM 엔터티(사용자, 그룹, 역할)에 부여할 수 있는 최대 권한을 설정하기 위한 고급 기능
- 엔터티의 권한 경계 설정을 통해 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행할 수 있음.
- 리소스 기반 정책은 권한 경계에 제한을 받지 않음
앞에서 생성한 사용자에게 IAMFullAccess >> 직접 정책 연결 > 권한추가
권한경계설정 >> AmazonEC2FullAccess
- 다시 IAM 액세스 거부됨
->> 해당 하는 사용자가 가질 수 있는 최대권한 *그 권한이 있어도 경계
EC2에 들어가도 권한 설정되지 않았기 때문에 오류가 발생
>>EC2 권한 경계를 설정하면 IAM을 사용할 수 없음
* 자기계정에 대해서 AmazonEC2FullAccess 권한경계설정주의 > 별도의 유저 추가로 테스트
서비스 제어정책
- 조직의 권한을 관리할 수 있는 조직 정책 유형
- 조직의 모든 계정에 사용 가능한 최대 권한에 대한 중앙 제어
ACL( 접근 제어 목록 )
- 리소스에 접근할 수 있는 다른 계정의 보안 주체를 제어 서비스 정책
- Json 정책 문서형식을 사용하지 않는 유일한 정책
- S3, WAF, VPC 는 ACL을 지원하는 서비스
세션 정책
- 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 정책
- AssumeRole, AssumeRoleWithSAML, AssumeRoleWithIdentity API 작업을 사용해서 세션을 생성하고 세션 정책을 전달
JSON : 자바스크립트 객체를 표현하는 방법
- 파이썬 딕셔너리 형태
- 기종 간의 데이터 교환시 표준
- 쉽게 확장가능
JSON 정책 문서 구조 (취약점 진단시 필요)
- 문서 상단에 위치하는 정책 전반의 선택적 정보
- 하나 이상의 Statement로 구성
- 각 Statement에는 단일 권한에 대한 정보가 포함
JSON 정책 요소
- Version: 정책 문서에 언어의 버전 정의 (2012-10-17버전 권장)
- Statement : 단일문 또는 개별문의 배열을 포함
ex) "Statement" : [{...},{....},{....}]
- Sid(선택사항) : 선택 설명문 ID를 포함하여 설명문들을 구분
- Effect : 문의 허용 또는 명시적 거부를 지정/ Allow 또는 Deny 값을 가짐 (대소문자 구분) / 액세스 허용시 allow
- Principal : 사용자 표시
- Action (필수항목) : 특정 작업에 허용 또는 거부 여부를 지정
- Resource (필수항목) : 문에서 다루는 객체를 ARN을 사용해 지정
- Condition(선택사항): 정책에서 권한을 부여하는 상황을 지정
예시
- 자격 증명 기반 정책
- S3: ListBucket
- example_bucket이라는 하나의 S3 버킷 목록을 허용하는 정책
- 리소스 기반 정책
- 특정 AWS 계정 구성원이 mybucket 내 버킷 또는 객체에 수행할 수 있는 모든 작업을 허용
- 버킷또는 모든 버킷
모든 리소스에 모든 동작을 허용
안전한 권한 부여 방법
- 최소 권한 부여
- IAM 정책시에 최소권한만 부여 사용자의 수행 파악후 사용자에 대한 정책 작성
방법1, 모든 리소스에 모든 동작을 허용 >> 필요이상의 권한 >> 안전하지 않음
{
"Resource": "*",
"Action": "*",
"Effect": "Allow",
}
방법2, DynamoDB 액션을 구체화 => DynamoDB의 모든 테이블에 대해서 read/write 가능 >> 다른 테이블에 대해서도 접근 가능하므로 안전하지 않음.
{
"Resource": "*",
"Action": [
"dynamodb:GetItem", << DynamoDB에 대한 구체적인 동작
"dynamodb:PutItem"
],
"Effect": "Allow",
}
방법3, 특정 DynamoDB 리소스로 한정 >> myDynamoDBTable 테이블에 대해선 read/write 하도록 제한
{
"Resource": "arn:aws:dynamodb:us-east-2:123456'/89012:table/myDynamoDBTable", <<사용할 테이블 지정
"Action": [
"dynamodb:GetItem", << DynamoDB에 대한 구체적인 동작
"dynamodb:PutItem"
],
"Effect": "Allow",
}
방법4, 특정 조건을 명시 >> ip주소가 1.2.3.4 에서 접근하는 경우에만 myDynamoDBTable에 대해서만 읽고 쓰고 하도록 제한
{
"Resource": "arn:aws:dynamodb:us-east-2:123456'/89012:table/myDynamoDBTable", <<사용할 테이블 지정
"Action": [
"dynamodb:GetItem", << DynamoDB에 대한 구체적인 동작
"dynamodb:PutItem"
],
"Effect": "Allow",
"condition":[
"ipAddress:{
"aws:SourceIP": "1.2.3.4" << 소스 IP를 제한
}
]
}
역할(Role)
- 특정 서비스에서 생성한 객체에 권한을 부여하는데 사용
IAM 실습
기존에 생성한 사용자를 삭제
csrf >> 서버 측에 요청이 갔을 때 정상적인 요청이 아니고 똑같은 요청으로 스크립트 코드로 만들어진 요청
- 정상적인 요청 확인 여부 (캡챠)
#0 실습개요
-xxx << 발급받는 계정의 끝 번호
#1 user-1, user-2, user-3사용자를 생성
#2 그룹 이름 정의
S-3Support
user-1 사용자를 그룹에 추가
user-2
#S3-Support 그룹에 S3
인라인 정책
- stopinstances
- startinstances
- describeinstaces
EC2 인스턴스 생성
- ec2에서 리전 확인
- 생성
이름 설정 > 이미지 (아마존) > 인스턴스 유형 t2.micro (해당하는 region에 맞춰서 선택) > 키페어 생성 (원격으로 > 네트워크 설정
- S3 버킷 생성
*버킷 이름 중복 주의
엣지에서 user-1 로그인
발급받은 계정으로 s3에 업로드
user-1 계정에서 업로드된거 확인
>> user-1 사용자는 S3-Support 사용자 그룹에 속해 있고, 해당 그룹은 S3ReadOnly 권한을 가지고 있어서 목록 및 정보 조회 파일 목록 조회가 가능
>>>AmazonS3ReadOnlyAccess 는 모든 버킷에 관해서 읽어들일 수 있음.
user-1 사용자가 버킷에 파일을 업로드?
>>user- 1사용자에게 쓰기 권한은 없기 때문에 upload는 안됨
ec2 대시보드에 들어가도 권한 없음
***실습이 끝나면 EC2 인스턴스 중지
'수업' 카테고리의 다른 글
| 12/4: AutoScaling (0) | 2023.12.01 |
|---|---|
| 12/1: vpc, ec2 (0) | 2023.12.01 |
| 11/27 : 데이터 3법 (0) | 2023.11.27 |
| 11/24 - 데이터 3법 (0) | 2023.11.24 |
| 11/23 (0) | 2023.11.23 |