AWS SSM을 사용한 SSH 로깅 및 세션 관리

Linux에서 SSH 로그를 유지하기 위해 사용자 정의 도구 또는 스크립트를 설정하는 것은 지루하고 오류가 발생하기 쉽습니다.

엔지니어는 rootsh , screen 또는 다른 유틸리티를 사용하여 사용자 활동을 기록할 수 있지만 사용자 권한이 올바르게 설정되지 않은 경우 숙련된 사용자는 감사 로그를 지워서 추적할 수 있습니다. 또 다른 옵션은 커널 수준에서 로깅을 설정하는 것이지만 이에 필요한 전문 지식은 그리 일반적이지 않습니다.

고맙게도 단일 Linux 명령을 작성하지 않고도 사용자 활동을 기록할 수 있는 방법이 있습니다! 다음 서비스가 필요합니다.

• EC2
• IAM(신원 및 액세스 관리)
• KMS(키 관리 서비스)
• CloudWatch Logs(및/또는 S3)
• AWS 시스템 관리자(이전의 SSM)

각각의 설정 방법을 살펴보겠습니다.

EC2 및 IAM

EC2 인스턴스를 시작하는 것은 일반적으로 상당히 쉽지만 시작하는 동안 수행해야 하는 한 가지 핵심 작업이 있습니다. 인스턴스에 IAM 역할을 연결해야 합니다. 그렇지 않으면 이 끝부분에 자세히 설명된 예상 결과를 얻을 수 없습니다. 기사.

EC2 인스턴스와 연결하는 IAM 역할에는 기본 제공 AmazonSSMManagedInstanceCore 정책과 이 정책(인라인 또는 고객 관리형으로 연결됨)이 있어야 합니다.

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

IAM 역할 외에도 일반적으로 다음 EC2 인스턴스 구성을 사용합니다.

• OS 는 기본적으로 AWS Systems Manager 에이전트(SSM 에이전트)가 설치된 상태로 제공되기 때문에 Amazon Linux 2입니다. (옵션이기도 한 Ubuntu 배포판도 마찬가지입니다.)
• 인스턴스 유형 은 t3.micro입니다(그러나 모든 유형이 가능함).
• 이 연습에서는 SSH 포트를 열 필요가 없으므로 AWS가 VPC에 할당하는 기본 보안 그룹 이 작동합니다.

EC2 인스턴스가 부팅될 때까지 기다리지 않고 KMS 설정을 시작할 수 있습니다.

KMS

CloudWatch에 전달되는 모든 세션 로그를 암호화하여 저장하려면 KMS 키가 필요합니다. KMS 서비스로 이동하여 키를 생성해 보겠습니다.

AWS 계정 루트 사용자가 아닌 다른 사용자가 키를 관리할 수 있도록 관리자를 할당하는 것이 좋지만 다른 사용자가 액세스 권한이 필요하지 않은 경우 3단계를 건너뛸 수 있습니다.

여기에서 IAM 사용자 "admin"을 키 관리자로 선택했지만 사용자 또는 역할을 자유롭게 선택할 수 있습니다. 관리자에 대한 키 삭제 권한을 비활성화하도록 선택할 수도 있습니다.

SSH 로그 암호화 및 암호 해독 작업을 위해 CloudWatch Logs 서비스에서만 이 키를 사용하기를 원하기 때문에 이 키에 사용자를 할당하지 않습니다.

검토 페이지에서 CloudWatch Logs가 키를 사용할 수 있는 권한이 포함되어 있지 않기 때문에 KMS 생성 키 정책을 변경해야 합니다. 다음 정책으로 대체하겠습니다.

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

모든 자리 표시자를 교체해야 합니다.

• ACCOUNT_ID 는 AWS 계정 ID가 됩니다.
• USERNAME 은 3단계에서 선택한 관리자 사용자 이름이 됩니다. 해당 단계에서 선택 해제한 경우 여기에서 두 번째 명령문 블록( "Sid": "Allow access for Key Administrators" 가 있는 블록)을 제거합니다.
• REGION 은 우리가 서비스를 배포할 지역 식별자 코드가 됩니다(예: us-west-1 ).

이로써 KMS는 준비가 되었습니다.

CloudWatch 로그 그룹

다음으로 SSM 에이전트가 SSH 세션 로그를 보낼 수 있는 CloudWatch Log 그룹(및/또는 S3 버킷 - 아래 참조)이 필요합니다. 만들어 봅시다.

KMS 키 ARN 필드에 유의하십시오. AWS는 KMS 섹션의 5단계에서 키를 생성한 후 여기에 필요한 값을 제공합니다.

(이전에 올바른 정책을 KMS 키에 연결하지 않아 CloudWatch Logs 서비스가 키를 사용하도록 허용한 경우 이 시점에서 KMS 키와 관련된 오류를 수신하게 됩니다.)

S3 버킷에 SSH 로그 저장

CloudWatch Logs 대신 또는 CloudWatch Logs에 추가하여 S3에 활동 로그를 저장하려면 이러한 권한을 EC2 인스턴스 프로필에 별도의 정책으로 추가해야 합니다(또는 연결해야 할 수 있는 다른 권한과 수동으로 결합해야 함).

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

위의 스니펫에서 BUCKET_NAME 자리 표시자를 교체해야 합니다.

이제 로그를 저장할 위치(CloudWatch Logs, S3 버킷 또는 둘 다)를 설정했으므로 SSH 세션을 활용할 준비가 되었습니다.

AWS 시스템 관리자 세션 관리자

이것은 SSH 세션 모니터링 및 로깅을 위해 Linux 시스템에 대한 보안 액세스를 구성하는 마지막 핵심 단계입니다. 세션 관리자 대시보드에서 시작하겠습니다.

대시보드에서 오른쪽 상단의 "세션 시작" 상자에 있는 흰색 "기본 설정 구성" 버튼을 클릭하여 세션 로깅을 활성화합니다.

기본 설정 페이지에서 탐색할 수 있는 여러 섹션을 찾을 수 있지만, 우리는 SSH 세션 로그를 CloudWatch 또는 S3로 스트리밍하여 Linux 시스템 내에서 무슨 일이 일어나는지 빠르게 볼 수 있도록 하는 데 중점을 둘 것입니다.

"CloudWatch 로깅" 섹션 바로 뒤에 버킷을 선택할 수 있는 "S3 로깅" 섹션이 있습니다.

SSH 로깅이 구성되면 Linux 시스템에 SSH로 연결하고 일부 명령을 실행하여 활동이 캡처되는지 여부를 확인할 수 있습니다.

세션을 시작하겠습니다. 같은 페이지에서 세션을 시작할 수 있는 "세션" 탭을 찾을 수 있습니다. "세션 시작" 버튼을 클릭하면 세션을 시작할 수 있는 EC2 머신 목록이 표시됩니다.

목록에 EC2 Linux 인스턴스가 표시되지 않으면 해당 인스턴스가 실행 상태이고 앞에서 설명한 것과 관련된 IAM 권한이 있는지 확인해야 합니다.

SSM 에이전트 "스트리밍 로그를 지원하지 않음" 오류 처리

EC2 시스템에 설치된 SSM 에이전트 버전이 CloudWatch 로그 스트리밍을 지원하지 않는다는 오류가 표시되더라도 걱정하지 마십시오. 고통 없이 해결할 수 있는 방법이 있습니다.

SSM 에이전트를 업데이트하려면 AWS Systems Manager 서비스의 왼쪽 패널에서 Run Command 로 이동해야 합니다.

일단 거기에 도착하면 주황색 "명령 실행" 버튼을 클릭하면 일부 매개변수를 채울 수 있는 새 페이지로 연결됩니다.

목록에서 AWS-UpdateSSMAgent 를 선택하여 시작하겠습니다.

선택되면 "대상" 섹션이 표시될 때까지 아래로 스크롤합니다. SSM 에이전트를 업데이트할 EC2 인스턴스를 선택한 다음 마지막에 "실행" 버튼을 눌러야 합니다. 업데이트 진행 상황을 모니터링할 수 있는 페이지로 이동합니다.

에이전트 업데이트는 5분 이상 걸리지 않습니다. 완료되면 세션 관리자에서 다시 세션을 생성할 수 있습니다.

이 시점에서 SSH 세션이 시작되어야 합니다.

몇 가지 명령을 실행한 후 CloudWatch Logs 로그 그룹(또는 S3 버킷, 표시되지 않음)으로 이동하여 활동이 기록되고 있는지 확인하겠습니다.

이제 미사용 암호화가 활성화된 설정이 있어 Linux 시스템에서 실행된 모든 명령을 기록합니다.

사실, 모든 명령은 우리가 원하는 것 이상일 수 있습니다. 세션 중에 제공되거나 생성된 모든 비밀은 CloudWatch 또는 S3에 기록되며 필요한 권한이 있는 모든 사람이 볼 수 있습니다. 이를 방지하기 위해 stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; 세션 중에 제공해야 하는 각 비밀에 대해.

사소한 주의 사항이 있는 훌륭한 SSM/SSH AWS 로깅 솔루션

세션 관리자는 포트 22를 열지 않고도 AWS의 가상 머신에 원격으로 액세스할 수 있는 유용한 도구입니다. 실제로 세션 관리자로 포트 전달 또는 직접 SSH 연결을 사용하는 경우 SSH 로그를 생성할 수 없습니다. 문서 참고 사항.

그럼에도 불구하고 세션 관리자와 세션 로깅을 결합하는 것은 VM 내 활동을 제어하고 모니터링하기 위한 강력한 솔루션입니다. 또한 Session Manager 서비스 사용에 대해서는 요금이 부과되지 않습니다. EC2 인스턴스와 CloudWatch Logs 또는 로그 저장을 위한 S3 버킷에 대해서만 비용을 지불합니다.

비디오 자습서를 선호하는 독자를 위해 YouTube에서 매우 유사한 절차를 조금 더 자세히 다루었습니다.

Toptal 엔지니어링 블로그에 대한 추가 정보:

• 사례 연구: 내 제품에 AWS 클라우드 인프라를 사용하는 이유