TRACE

원본

A company hosts a data lake on AWS. The data lake consists of data in Amazon S3 and Amazon RDS for PostgreSQL. The company needs a reporting solution that provides data visualization and includes all the data sources within the data lake. Only the company's management team should have full access to all the visualizations. The rest of the company should have only limited access. Which solution will meet these requirements?

A. Create an analysis in Amazon QuickSight. Connect all the data sources and create new datasets. Publish dashboards to visualize the data. Share the dashboards with the appropriate IAM roles.

B. Create an analysis in Amazon QuickSight. Connect all the data sources and create new datasets. Publish dashboards to visualize the data. Share the dashboards with the appropriate users and groups.

C. Create an AWS Glue table and crawler for the data in Amazon S3. Create an AWS Glue extract, transform, and load (ETL) job to produce reports. Publish the reports to Amazon S3. Use S3 bucket policies to limit access to the reports.

D. Create an AWS Glue table and crawler for the data in Amazon S3. Use Amazon Athena Federated Query to access data within Amazon RDS for PostgreSQL. Generate reports by using Amazon Athena. Publish the reports to Amazon S3. Use S3 bucket policies to limit access to the reports.

번역본

한 회사가 AWS에서 데이터 레이크를 호스팅합니다. 데이터 레이크는 Amazon S3와 PostgreSQL용 Amazon RDS의 데이터로 구성됩니다. 이 회사는 데이터 시각화를 제공하고 데이터 레이크 내의 모든 데이터 소스를 포함하는 보고 솔루션이 필요합니다. 회사의 경영진만 모든 시각화에 대한 전체 액세스 권한을 가져야 합니다. 나머지 회사는 제한된 액세스 권한만 가져야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. Amazon QuickSight에서 분석을 만듭니다. 모든 데이터 소스를 연결하고 새로운 데이터 세트를 만듭니다. 대시보드를 게시하여 데이터를 시각화 합니다. 적절한 IAM 역할과 대시보드를 공유합니다.

B. Amazon QuickSight에서 분석을 만듭니다. 모든 데이터 소스를 연결하고 새로운 데이터 세트를 만듭니다. 대시보드를 게시하여 데이터를 시각화 합니다. 적절한 사용자 및 그룹과 대시보드를 공유합니다.

C. Amazon S3의 데이터에 대한 AWS Glue 테이블과 크롤러를 만듭니다. AWS Glue 추출, 변환 및 로드(ETL) 작업을 만들어 보고서를 생성합니다. 보고서를 Amazon S3에 게시합니다. S3 버킷 정책을 사용하여 보고서에 대한 액세스를 제한합니다.

D. Amazon S3의 데이터에 대한 AWS Glue 테이블과 크롤러를 만듭니다. Amazon Athena Federated Query를 사용하여 PostgreSQL용 Amazon RDS 내의 데이터에 액세스합니다. Amazon Athena를 사용하여 보고서를 생성합니다. 보고서를 Amazon S3에 게시합니다. S3 버킷 정책을 사용하 여 보고서에 대한 액세스를 제한합니다.

문제 분석

✅ AWS에 데이터 레이크(Data Lake)를 운영 중
✅ Amazon S3와 Amazon RDS for PostgreSQL을 데이터 저장소로 사용
✅ 데이터 시각화(Reporting & Visualization) 솔루션이 필요
✅ 경영진(Management Team)만 전체 데이터 접근 가능, 다른 직원들은 제한된 접근만 가능해야 함

➡ 핵심 요구사항:

1. S3와 RDS 데이터를 모두 연결할 수 있어야 함
2. 시각화(대시보드) 기능이 필요함
3. 사용자별 접근 제어(권한 관리)가 가능해야 함

정답: B. Amazon QuickSight (사용자 및 그룹 기반 공유) 🎯✅

✅ Amazon QuickSight는 S3 & RDS 데이터를 시각화할 수 있음
✅ 대시보드를 제공하여 경영진과 직원의 접근 권한을 다르게 설정 가능
✅ IAM 역할뿐만 아니라, 사용자 및 그룹별로 대시보드 접근을 제어 가능

➡ 따라서 가장 적절한 정답은 B 🚀

원본

A company recently migrated to AWS and wants to implement a solution to protect the traic that jows in and out of the production VPC. The company had an inspection server in its on-premises data center. The inspection server performed speci+c operations such as traic jow inspection and traic +ltering. The company wants to have the same functionalities in the AWS Cloud. Which solution will meet these requirements?

A. Use Amazon GuardDuty for traic inspection and traic +ltering in the production VPC.

B. Use Traic Mirroring to mirror traic from the production VPC for traic inspection and +ltering.

C. Use AWS Network Firewall to create the required rules for traic inspection and traic +ltering for the production VPC.

D. Use AWS Firewall Manager to create the required rules for traic inspection and traic +ltering for the production VPC.

번역본

한 회사가 최근 AWS로 마이그레이션했고 프로덕션 VPC에서 유입되고 유출되는 트래픽을 보호하는 솔루션을 구현하려고 합니다. 이 회사는 온프레미 스 데이터 센터에 검사 서버를 두었습니다. 검사 서버는 트래픽 흐름 검사 및 트래픽 필터링과 같은 특정 작업을 수행했습니다. 이 회사는 AWS 클라우드 에서 동일한 기능을 원합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 프로덕션 VPC에서 트래픽 검사 및 트래픽 필터링을 위해 Amazon GuardDuty를 사용합니다.

B. 트래픽 미러링을 사용하여 프로덕션 VPC의 트래픽을 미러링하여 트래픽 검사 및 필터링을 수행합니다.

C. AWS 네트워크 방화벽을 사용하여 프로덕션 VPC에 대한 트래픽 검사 및 트래픽 필터링에 필요한 규칙을 만듭니다.

D. AWS Firewall Manager를 사용하여 프로덕션 VPC에 대한 트래픽 검사 및 트래픽 필터링에 필요한 규칙을 만듭니다.

문제 분석

✅ 회사가 AWS로 마이그레이션했음
✅ 이전에는 온프레미스 데이터 센터에서 트래픽을 검사하고 필터링하는 전용 서버를 사용했음
✅ AWS에서도 동일한 기능을 유지하려 함
✅ VPC의 트래픽 흐름을 검사 및 필터링할 수 있어야 함

➡ 즉, VPC 내에서 네트워크 트래픽을 검사하고 필터링할 수 있는 AWS 네트워크 보안 서비스가 필요함.

C. AWS Network Firewall 사용 ✅ (정답)

• AWS Network Firewall은 VPC 내부의 트래픽을 검사하고 필터링하는 AWS 서비스야.
• 사용자가 직접 보안 규칙을 생성할 수 있으며, Stateful 및 Stateless 트래픽 필터링을 지원.
• VPC 내에서 직접 악성 트래픽을 차단할 수 있음.
• 즉, 온프레미스에서 사용하던 트래픽 검사 및 필터링 기능을 그대로 AWS에서 구현 가능함.

✅ 트래픽 검사 및 필터링을 수행하는 AWS 서비스이므로 정답🎯

원본

A company runs an ecommerce application on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. The Auto Scaling group scales based on CPU utilization metrics. The ecommerce application stores the transaction data in a MySQL 8.0 database that is hosted on a large EC2 instance. The database's performance degrades quickly as application load increases. The application handles more read requests than write transactions. The company wants a solution that will automatically scale the database to meet the demand of unpredictable read workloads while maintaining high availability. Which solution will meet these requirements?

A. Use Amazon Redshift with a single node for leader and compute functionality. 

B. Use Amazon RDS with a Single-AZ deployment Con+gure Amazon RDS to add reader instances in a different Availability Zone.

C. Use Amazon Aurora with a Multi-AZ deployment. Con+gure Aurora Auto Scaling with Aurora Replicas.

D. Use Amazon ElastiCache for Memcached with EC2 Spot Instances. 

번역본

한 회사가 애플리케이션 로드 밸런서 뒤의 Amazon EC2 인스턴스에서 전자상거래 애플리케이션을 실행합니다. 인스턴스는 여러 가용성 영역에 걸쳐 Amazon EC2 자동 확장 그룹에서 실행됩니다. 자동 확장 그룹은 CPU 사용률 메트릭에 따라 확장됩니다. 전자상거래 애플리케이션은 대규모 EC2 인스 턴스에 호스팅된 MySQL 8.0 데이터베이스에 트랜잭션 데이터를 저장합니다. 애플리케이션 부하가 증가함에 따라 데이터베이스 성능이 빠르게 저하됩니다. 애플리케이션은 쓰기 트랜잭션보다 더 많은 읽기 요청을 처리합니다. 이 회사는 높은 가용성을 유지하면서 예측할 수 없는 읽기 워크로드의 수요를 충족하도록 데이터베이스를 자동으로 확장하는 솔루션을 원합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 리더 및 컴퓨팅 기능에 단일 노드를 갖춘 Amazon Redshift를 사용합니다.

B. 단일 AZ 배포로 Amazon RDS 사용 다른 가용성 영역에 리더 인스턴스를 추가하도록 Amazon RDS를 구성합니다.

C. Amazon Aurora를 Multi-AZ 배포와 함께 사용합니다. Aurora Replicas로 Aurora Auto Scaling을 구성합니다.

D. EC2 스팟 인스턴스와 함께 Memcached에 Amazon ElastiCache를 사용합니다

문제 분석

✅ 이커머스 애플리케이션이 EC2 + Auto Scaling을 사용해서 실행 중
✅ CPU 사용률에 따라 자동 확장
✅ MySQL 8.0 데이터베이스가 EC2 인스턴스에서 실행 중
✅ 읽기 요청이 많고, 쓰기 트랜잭션보다 읽기 부하가 큼
✅ 데이터베이스 성능이 부하 증가 시 빠르게 저하됨
✅ 읽기 성능을 자동으로 확장하면서 고가용성을 유지해야 함

➡ 핵심 요구사항:

1. 읽기 성능을 자동 확장
2. 고가용성 유지
3. 예측 불가능한 부하 증가에도 대응 가능해야 함

C. Amazon Aurora Multi-AZ + Aurora Auto Scaling ✅ (정답)

• Amazon Aurora는 MySQL 호환 고성능 데이터베이스 서비스로,
  • 기본적으로 고가용성을 제공 (Multi-AZ 배포 가능)
  • Aurora Auto Scaling을 사용해 읽기 복제본을 자동 확장 가능
  • 기본적으로 성능이 MySQL보다 훨씬 뛰어남 (최대 5배 빠름)
• 읽기 부하가 많을 경우, Aurora Replicas(읽기 복제본)가 자동으로 추가 및 제거됨.
• 스토리지가 자동 확장되므로, 용량 걱정 없이 사용 가능.
• 읽기 성능이 필요한 애플리케이션에 최적화되어 있음.

✅ 읽기 부하를 자동으로 확장할 수 있고, 고가용성을 유지할 수 있으므로 가장 적절한 솔루션

원본

A company performs monthly maintenance on its AWS infrastructure. During these maintenance activities, the company needs to rotate the credentials for its Amazon RDS for MySQL databases across multiple AWS Regions. Which solution will meet these requirements with the LEAST operational overhead?

A. Store the credentials as secrets in AWS Secrets Manager. Use multi-Region secret replication for the required Regions. Con+gure Secrets Manager to rotate the secrets on a schedule.

 

B. Store the credentials as secrets in AWS Systems Manager by creating a secure string parameter. Use multi-Region secret replication for the required Regions. Con+gure Systems Manager to rotate the secrets on a schedule.

 

C. Store the credentials in an Amazon S3 bucket that has server-side encryption (SSE) enabled. Use Amazon EventBridge (Amazon CloudWatch Events) to invoke an AWS Lambda function to rotate the credentials.

 

D. Encrypt the credentials as secrets by using AWS Key Management Service (AWS KMS) multi-Region customer managed keys. Store the secrets in an Amazon DynamoDB global table. Use an AWS Lambda function to retrieve the secrets from DynamoDB. Use the RDS API to rotate the secrets.

번역본

한 회사가 AWS 인프라에 대해 월별 유지 관리를 수행합니다. 이러한 유지 관리 활동 중에 회사는 여러 AWS 지역에서 Amazon RDS for MySQL 데이터 베이스의 자격 증명을 순환해야 합니다. 어떤 솔루션이 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. 자격 증명을 AWS Secrets Manager의 비밀로 저장합니다. 필요한 리전에 다중 리전 비밀 복제를 사용합니다. Secrets Manager를 구성하여 일정에 따라 비밀을 순환합니다.

B. 보안 문자열 매개변수를 생성하여 AWS Systems Manager에서 자격 증명을 비밀로 저장합니다. 필요한 Region에 대해 다중 Region 비밀 복제를 사용합니다. Systems Manager를 구성하여 일정에 따라 비밀을 순환합니다.

C. 서버 측 암호화(SSE)가 활성화된 Amazon S3 버킷에 자격 증명을 저장합니다. Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 AWS Lambda 함수를 호출하여 자격 증명을 회전합니다.

D. AWS Key Management Service(AWS KMS) 다중 지역 고객 관리 키를 사용하여 자격 증명을 비밀로 암호화합니다. Amazon DynamoDB 글로벌 테이블에 비밀을 저장합니다. AWS Lambda 함수를 사용하여 DynamoDB에서 비밀을 검색합니다. RDS API를 사용하여 비밀을 순환합니다.

문제 분석

회사가 매달 AWS 인프라 유지보수를 진행하는데, 그 과정에서
✅ Amazon RDS for MySQL 데이터베이스의 자격 증명(credential)을 여러 AWS 리전에서 교체(rotate)해야 함
✅ 운영 부담(Operational Overhead)이 가장 적은 방법을 찾아야 함

➡ 즉, 자동으로 RDS 데이터베이스 자격 증명을 주기적으로 교체할 수 있는 서비스가 필요하고,
➡ 여러 리전에서 쉽게 동작할 수 있어야 함.

A. AWS Secrets Manager를 사용하여 자동 자격 증명 교체 ✅ (정답)

• AWS Secrets Manager는 AWS에서 제공하는 보안 자격 증명 관리 서비스
• 자동으로 RDS 데이터베이스 자격 증명을 주기적으로 변경(rotate)할 수 있음.
• 멀티 리전 복제 기능이 있어서 여러 리전에서도 자격 증명을 자동으로 동기화할 수 있음.
• 따라서 운영 부담이 가장 적고, AWS에서 권장하는 방식임.

✅ 이 방식이 가장 효율적이고, 운영 부담이 적으므로 정답

안드로이드 Magisk 루팅 방법(갤럭시 S7)
https://m.blog.naver.com/timeless947/221927525919

TWRP (모드 진입 : 갤럭시 S7 기준으로 볼륨'상'키+전원키+가운데키)
https://dl.twrp.me/herolte/

안드로이드 순정 펌웨어 다운로드를 위한 samfirm (갤럭시 S7)
https://rgy0409.tistory.com/4509
https://rgy0409.tistory.com/3510
https://hackcatml.tistory.com/93

> samfirm 프로그램 막혔음
https://hackcatml.tistory.com/93
https://samfw.com/firmware/SM-G930K/KTC/G930KKKU3EVG2

삼성 오딘3(Odin) 사용하여 스마트폰 복원 방법
https://seo-security.tistory.com/35

※ 안드로이드 순정 설치할 시 주의할 점※

1. 오딘3 버전에 따라서 결과(성공, 실패)가 다를 수 있음. 현재 나는 v3.13버전 사용중.

이전 버전 사용하니, 순정 설치 실패함

2. 순정을 설치하고, 폰을 재부팅할 때, 리커버리 모드에 진입하여

>> Wipe data/facroty reset - yes을 무조건 먼저하고 나서, Reboot system now를 진행해야 한다.

(안 그러면 무한 로딩 걸릴지도..)

1. 데몬 관리

웹 서버 데몬이 root계정으로 운영될 경우, 웹 애플리케이션 취약점이나 buffer overflow 등을 이용하는 공격자에게 root 권한을 유출할 수 있음

[판단 기준]

양호 - webtob 데몬이 root 계정으로 운영되지 않도록 전용 계정으로 구동한 경우

취약 - webtob 데몬이 root 계정으로 운영되지 않도록 전용 계정으로 구동하지 않은 경우

[확인 방법]

#ps -ef | grep webtob 에서 root 이외의 계정으로 구동되는지 확인

(결과예시)

adm01 31012  1  0  Mar 28 ?  00:12:28 wsm -I 0x2 -l webtob

root 31012  1  0  Mar 28 ?  00:14:11 htl -I 0x2 -l webtob

adm01 31012  1  0  Mar 28 ?  00:14:48 hth -I 0x2 -l webtob

root 로 보인다고 해서 무조건 취약이 아니다. 

아래 사항을 파악해야 한다.

1) root 계정으로 운영 시

Well-known 포트는 root 로만 구동이 가능.

Root 권한의 80번 포트를 사용하여 구동되어진 경우 1024번 포트 이상의 전용 계정으로 구동하도록 권장

서비스 영향도 존재 시, 취약 - 위험수용(장기)

2) WebtoB 전용 계정으로 운영 시

WebtoB 전용 계정으로 운영 시에도 htl 프로세스의 경우 root 권한을 부여해야 실행가능함(sticky-bits 부여 등)

따라서 /bin 폴더에 있는 htl 프로세스의 권한 부여 현황 확인(ls -al 등)이 추가적으로 필요

전용계정으로 운영 중이나, htl 실행을 위해 sticky-bits 부여한 경우 양호처리

2. 관리서버 디렉터리 권한 설정

일반 사용자가 관리 서버 디렉터리에 접근할 경우 홈페이지 변조, 설정 변경 등으로 인한 장애가 발생할 수 있으므로 관리 서버 디렉터리에 대한 일반 사용자의 접근 권한을 제한해야 함

[판단 기준]

양호 - 관리서버 디렉터리에 일반 사용자가 접근할 수 없도록 권한이 750인 경우

취약 - 관리서버 디렉터리에 일반 사용자가 접근할 수 없도록 권한이 750이 아닌 경우

[확인 방법]

1. Unix

1) 관리서버 디렉터리 위치 확인

#vi [WebtoB_HOME]/config/http.m

*NODE

  WEBTOBDIR= "/home/user/webtob",

...

2) 관리서버 디렉터리(ServerRoot) 권한 확인

(결과예시)

[ServerRoot] /adm0101/jeus/webtob

drwxrwxr-x 16 adm01 adm01 4096 Mar 10 2021 .  >> 취약

2. Windows

Administrator 또는 전용 웹 서버 계정 소유이고

전용 웹 서버 계정 그룹(Administrator)(모든 권한)

Users 그룹(쓰기 권한 제거), Everyone 그룹(그룹 제거) 확인

[명령어]

lcalcls %WEBTOBDIR%

3. 헤더 정보 노출 방지

공격자가 대상 시스템의 정보를 획득하기 위해 고의적으로 웹 서버 헤더 정보를 유출 유도할 수 있음

[판단 기준]

양호 - 헤더 정보 노출을 제한한 경우

취약 - 헤더 정보 노출을 제한하지 않은 경우

[확인 방법]

[WEBTOB_HOME]/config/http.m 파일에서 'ServerTokens'의 값이 'OFF' 인지 확인

##여기서 주의할 점##

최신 버전의 WebtoB 는 환경 설정 파일 내에 ServerTokens=OFF 설정이 없지만 default로 OFF 되어있는 경우가 있다.

wasadm(어드민 접속 명령어)를 통해서 cfg -n 으로 확인해보면 Off 로 적용되어 있음을 확인할 수 있다. 

1. 먼저 컴파일, 디컴파일 등에 필요한 프로그램 설치가 먼저다

1) ApkStudio : APK 파일 변조 및 리패키징, 설치 등등 
2) APKToolGUI : APK > 디컴파일 (그 전에 JAVA 등 설치과정이 필요한데 프로그램에서 알려주는 데로 하면 됨)
3) jadx-gui : APK > 자바 소스코드


2. 이번에 할 방법은 [디컴파일 도구]를 통해 앱 분석 후, 루팅 탐지 함수를 확인하고 / [컴파일 도구]를 이용해 디스어셈블러화하여 루팅 탐지 함수의 코드를 항상 false 되게 변조하고 / 다시 [리패키징 및 sign 과정]을 거쳐 install을 할 예정

- 디컴파일 도구인 "jadx-gui"를 이용해 앱 분석 
(ctrl+shift+F로 텍스트 검색을 많이 활용한다)

- 루팅 탐지 함수를 찾았다면 해당 함수의 경로 및 이름 확인

- 컴파일 도구인 "ApkStudio"를 이용하여 함수(smali파일) 찾고 코드 변조 진행

- 리패키징: "Project - Build" 클릭 후 dist 폴더 생성 및 apk 파일 생성 확인
- Sign : 생성된 apk 파일 클릭한 상태에서 "Project - Sign/Export"
https://mkkbest.tistory.com/entry/%EC%9E%90%EB%B0%94-keytool-%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%83%9D%EC%84%B1

Java의 keytool.exe 있는 위치 찾아서 (일반적으로 Java/jdk/bin/keytool.exe)
cmd> keytool -genkey -v -keystore yr.keystore -alias yr -keyalg RSA -keysize 2048 -validity 3650
개인 인증서 생성 후 Sign 진행
(암호는 입력해야 제대로 앱이 리패키징 됨)

- Install : "Project - Install" 클릭 시 안드로이드 기기에 설치 완료됨
(안되면 https://info-lab.tistory.com/122 여기서 adb install 방법 확인) 

1. Windows에 Frida 설치
cmd> pip install frida
cmd> pip install frida-tools

2. 프리다 버전 확인
cmd> frida --version

3. 안드로이드 기기에 frida server 설치 및 구동
https://github.com/frida/frida/releases
- 여기서 "아까 확인했던 frida 버전"과 "안드로이드 기기에 맞는 버전"을 다운로드 받기

+) "안드로이드 기기 버전 확인"
cmd> adb shell getprop | find "cpu"
결과예시> [ro.product.cpu.abi]: [arm64-v8a]
....
여기서 확인해야할 것은 cpu.abi >> "arm64"를 기억하자

- 다운로드(xz 파일) 받은 후 압축해제

- 안드로이드 기기에 파일 넣어주기
cmd> adb push [압축해제파일명] /data/local/tmp
cmd> adb shell
$ su  (root 계정으로 권한상승)
# cd /data/local/tmp (넣은 파일 있는 곳으로 이동)
# ls (넣은 파일 있는지 확인)
# chmod 755 [압축해제파일명] (실행권한 부여)
# ./frida-server-16.1.3-android-arm64 & (백그라운드&에서 frida-server 구동)

※ 만약, 'Unable to start : Error binding to address 127.0.0.1:27042: Address already in use' 에러가 떴다면, frida-server가 이미 돌아가고 있다는 뜻이기 때문에 프로세스 종료 후 다시 구동시켜줘야 한다

# ps -ef | grep frida (frida라는 텍스트 들어간 프로세스id 확인)
# kill -9 [pid] (프로세스 강제 종료)
# ./frida-server-16.1.3-android-arm64 & (백그라운드&에서 frida-server 다시 구동)

4. 설치된 APK의 [패키지명] 확인
cmd> frida-ps -Uai (결과에서 Identifier를 보면 된다)
결과예시 >
  PID  Name             Identifier
-----  ---------------  ---------------------------------------
23384  Gmail            com.google.android.gm
15319  Google           com.google.android.googlequicksearchbox
21709  Google Play 스토어  com.android.vending
...

5. Frida 후킹 시작
cmd> frida -U -f [패키지명] -l [후킹파일명.js]
명령예시> frida -U -f com.google.android.gm -l hooking.js

후킹파일 예시)

Java.perform(function(){
	var obj = Java.use('q5.b');
	obj.n.overload().implementation = function(){
		console.log('[+] 루팅 완료');
		return false;
	}
});

□ 커버로스(Kerberos)란?

• 티켓(ticket) 기반의 컴퓨터 네트워크 인증 프로토콜. 클라이언트 서버 모델을 목적으로 개발되었으며 사용자와 서버가 서로 식별할 수 있는 상호 인증(양방향 인증)을 제공한다.
• 보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 요청을 받는 서버가 서로의 신뢰성을 확보하기위해 사용된다.

* 티켓(ticket) : 유저 아이디를 안전하게 전달하는 데 사용되는 정보 패킷으로, [유저 아이디, 유저 호스트의 IP 주소, 타임 스탬프(time stamp, 시간 기록), 티켓 수명을 정의하는 값, 세션 키] 등을 포함한다

□ 커버로스의 구성요소

- KDC(Key Distribution Center)

: 키 분배 서버(Kerberos에서 가장 중요한 시스템)

: 모든 사용자와 서비스들의 암호화키(비밀키, secret key)를 보유

: 신뢰할 수 있는 제3의 기관으로서 티켓을 생성, 인증서비스를 제공

: 클라이언트와 서비스는 KDC의 무결성을 신뢰하며, 이러한 신뢰는 커버로스 보안의 근간

: 사용자의 패스워드는 비밀키로 변환됨. 이 비밀키는 주체와 KDC 사이에서 "민감한 데이터를 전송"하기 위해 사용되며, "사용자 인증 목적"을 위해서도 사용됨

: TGS와 AS로 구성

- AS(Authentication Service)

: 실질적으로 인증을 수행

: 사용자에 대한 인증을 수행하는 KDC의 부분 서비스

- TGS(Ticket Granting Service)

: 티켓 부여 서비스

: 티켓을 부여하고 티켓을 분배하는 KDC의 부분 서비스

- SS(Service Server, Resource Server)

: 유저가 최종적으로 통신하고자 하는 목적지 서버

- Ticket

: 사용자에 대해 신원과 인증을 확인하는 토큰

: 사용자가 다른 주체들과 통신이 필요할 때마다 패스워드를 입력하지 않도록 도와 줌

- Principals

: 인증을 위하여 커버로스 프로토콜을 사용하는 모든 실체

□ 커버로스의 동작절차

1,2(Request TGT) : 사용자는 워크스테이션에 로그인하고 호스트의 서비스를 요청한다

3(TGT+Session Key) :  AS는 사용자가 DB에 접근권한이 있는지 확인한다. 그리고 TGT(Ticket Granting Ticket, 티켓을 받기 위한 티켓) 와 세션키를 생성한다. 그 결과물을 사용자의 패스워드로부터 유도한 키를 사용하여 암호화한다.

4(Request Ticket + Auth) : 워크스테이션은 사용자에게 프롬프트를 통해 패스워드를 묻고, 그것으로 수신되는 메시지를 복호화한 다음(유저는 당연히 자신의 패스워드를 알고 있으므로, AS로부터 받은 정보를 복호화하여 TGS 세션 키를 얻을 수 있다.) 사용자 이름, 네트워크 주소, TGS의 시간이 기록된 티켓과 인증자를 보낸다.

5(Ticket + Session Key) : TGS는 티켓과 인증자를 복호화하고, 요청을 확인하고 요청된 서버에 사용할 티켓을 생성한다.
6(Request Service + Auth) : 워크스테이션은 티켓과 인증자를 서버에 보낸다.

7(Server Authentication) : 서버는 티켓과 인증자가 일치되는지를 확인하고, 서비스에 대한 접근을 허락한다. 만약 쌍방 인증이 필요한 경우라면 서버는 인증자를 반환한다.

□ 특징

• 세션 키는 비밀 키와 다른 개념이다.
• 세션 키는 유저와 서비스 간의 통신에 필요한 키이다.
• 커버로스에서 유저는 TGS, SS와 통신을 하게 되므로, 두 개의 세션 키를 필요로 한다.
• 비밀 키는 서비스가 유저에게 만들어서 보내줄 티켓을 암호화하거나, 서비스가 유저로부터 전달받은 티켓의 복호화를 위해 가지고 있는 키이다.
• 티켓의 복호화를 위해 TGS는 TGS 비밀 키를 가지고 있고, SS는 SS 비밀 키를 가지고 있다.
• 티켓의 암호화를 위해 AS는 TGS 비밀 키를 가지고 있고, TGS는 SS 비밀 키를 가지고 있다.
• 또한 세션 키는 티켓 안에 들어갈 데이터 중 하나이기 때문에 AS는 TGS 세션 키를 가지고 있고, TGS는 SS 세션 키를 가지고 있다.

□ 커버로스의 장단점

https://jdh5202.tistory.com/916