OTP를 이용하여 AWS SSM 사용 가능 환경 구성

1. AWS 설정

2. 서버배포

3. 사용자

4. 어디와 통신을 하는가?

5. 왜 SUDO를 통해 관리하는가?

6. 편리함 외에 보안적인 이점이 있는지?

7. 추가로 있어야 하는 것들(이지만 당장 불가능... 공부도 해야되는데 ㅠ)

서버 배포 테라폼코드

GitHub - cjsrkd3321/cloud-security-platform-web-with-steampipe: cloud-security-platform-web-with-steampipe

사용자 요청 시 서버 설정하는 코드(ssm  폴더 참고)

회사에서 SSH를 중계해주는 시스템을 사용중이다.

당연히 보안을 위해서 최대한 안전하게 하는게 맞지만, 실제로 등록을 수행할때 퍼블릭키도 내가 만들어야되고, 결재를 거쳐서 등록도 해야되고, 온프렘이다보니 관리 공수나 자칫 배포가 잘못돼서 실제 현황이나 상태가 맞지 않는 경우도 있어 너무 불편했다.(개인적인 경험으론 퍼블릭키 등록 후 개인키를 내가 소유해야되고, 인스턴스 등록하는 과정에서의 일원화되지 않은 결재라인이 너무 힘들게 느껴졌다.)

그러다 몇몇 요건들을 갖추면 SSM을 사용가능하게 해준다고하여 주말을 불태워 구성해보게 됐다. 아키텍쳐는 아래와 같다.

AWS 설정

간단하게 한 장 요약본이다.

명령어 같은 경우 screen을 기반으로 기록하는데 요건에 따라 다르겠지만 로그 보관을 위해 cloudwatch, s3 둘 다 사용하거나 필요한 것만 사용하고 이를 kinesis나 eventbridge, lambda 등을 통해 SIEM으로 보내주면 된다. 실제로 로그는 아래와 같이 남게된다.

KMS Encryption 설정의 경우 원래 Fleet Manager를 통해 추가적인 행동을 하기 위해 설정했는데 현재 글의 내용만 따라하는데는 딱히 필요없을 것 같긴하다.

서버배포

1. 필수조건 : 서버 배포 시, ec2 intance profile에 AmazonSSMManagedInstanceCore 정책을 붙여준다.(ssm 사용을 위함)

2. 테라폼 코드

resource "aws_instance" "ssh-instance-with-otp" {
  ami           = "ami-0b1d3b1941f23c7d5" // ap-northeast-2
  instance_type = "t2.micro"

  subnet_id                   = data.aws_subnet.this.id
  availability_zone           = "ap-northeast-2a"
  associate_public_ip_address = true

  iam_instance_profile = "ec2-role-test"

  user_data = <<-EOF
    #!/bin/bash
    yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    yum install google-authenticator.x86_64 -y
    cp /etc/pam.d/su /etc/pam.d/su.bak
    awk '{if (NR==2) { print "auth required pam_google_authenticator.so nullok"; print $0 } else { print $0 } }' /etc/pam.d/su.bak > /etc/pam.d/su
  EOF
}

google-authenticator를 다운로드 한 후에 /etc/pam.d/su 파일 2번째 줄에 OTP 사용을 위한 조건 추가. su 파일 내용 아래와 같이 변경됨.

#%PAM-1.0
auth required pam_google_authenticator.so nullok
auth		sufficient	pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth		sufficient	pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth		required	pam_wheel.so use_uid
auth		substack	system-auth
auth		include		postlogin
account		sufficient	pam_succeed_if.so uid = 0 use_uid quiet
account		include		system-auth
password	include		system-auth
session		include		system-auth
session		include		postlogin
session		optional	pam_xauth.so

서버 배포가 완료된다.(실제로 사용할 땐 ami를 만들때 이미 설치해놓고 구우면 좋을 것 같다.)

사용자

1. 사용자가 사용 신청

2. web에서 run command를 통해 서버에 설정을 진행한다.

1. 사용자 추가(useradd -m USER)
2. /etc/sudoers.d/ssm-agent-users 삭제
3. 위 파일 내용 아래와 같이 수정(ssm-user는 특정 사용자만 sudo su - USER를 통해 접근 가능)

   1. # User rules for ssm-user
      ssm-user ALL=(ALL) NOPASSWD:/bin/su - USER

4. chmod 440 /etc/sudoers.d/ssm-agent-users
5. 사용자를 위한 sudo 파일 생성

   1. # User rules for USER
      USER ALL=(ALL) NOPASSWD:ALL

6. chmod 440 /etc/sudoers.d/USER-users
7. 사용자 홈 디렉토리에 .google_authenticator 파일 추가

   1. RANDOM_VALUE
      " RATE_LIMIT 3 30 INT_VAULE
      " DISALLOW_REUSE 12345678
      " TOTP_AUTH
      12345678
      12345678
      12345678
      12345678
      12345678

8. chown USER:USER /home/USER/.google_authenticator
9. chmod 400 /home/USER/.google_authenticator

3. 허용되면 Copy 버튼을 눌러 접속 명령어를 복사한다.(이때 사용자는 링크를 참조하여 사전에 플러그인 설치 필요)

aws ssm start-session --target INSTANCE_ID

4. 접속하여 정상동작하는지 확인한다.

sh-4.2$ sudo su

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for ssm-user:
sh-4.2$ sudo su - rexchun
Verification code:
Last login: Sun Jan 23 03:49:46 UTC 2022 on pts/0
[rexchun@ip-10-0-57-105 ~]$ sudo su
[root@ip-10-0-57-105 rexchun]#

기본적으로 모두 비밀번호가 없기 때문에 특정 유저에 대해서 sudo su - USER 하지 않으면 추가 접근이 불가능하다.

어디와 통신을 하는가?

cloudtrail 로그를 보면 위와 같이 웹소켓 주소를 보내준다.(이것때문에 초기 로그인 시에 OTP 설정을 하지 못했다.)

예상컨데 아마 웹소켓으로 화면을 스트리밍해주는 것으로 보인다.

실제로 연결은 위의 웹소켓 주소와 맺어지게 된다.

왜 SUDO를 통해 관리하는가?

아마 찾아보면 다들 ssh로 직접 접근할 때 OTP를 입력하도록 설정할 것이다. 하지만, AWS에서 StartSession 명령 입력 시 웹소켓으로 화면을 스트리밍해주기 때문에 초기에 OTP 설정이 불가능하다.

또한, SSH를 사용하게 되면 결국 사용자가 키 관리를 해야한다는 부담을 지우는 것과 마찬가지기 때문에 다른 위와 같은 방안을 강구하게 됐다.

편리함 외에 보안적인 이점이 있는지?

너무 많다. 당장 Fleet Manager만 보더라도 아래와 같이 API를 통해 간편하게 파일시스템을 가져올 수 있다.

추가로 간단히 API로만 세션도 관리 가능하고, 명령어도 일괄로 보낼 수 있다.

아마 서버 관리를 해본사람은 알겠지만 ansible을 쓰던 chef을 쓰던 실제로 명령이 유효하게 동작했는지 보장하기는 매우 어려운 일이다. 개인적인 생각으로는 본질에 집중하게 도와주는 기능들이 너무나 잘 구성되어있고, '운영'을 위해 사용하는 시간들을 매우 단축시켜줄 수 있을 것이라고 생각한다.(여기서 모두 언급은 못하지만 예방/탐지/대응/사후조치 등의 모든 프로세스를 경험해봤다면 현재 내가 쓰고 있는 내용들 뿐만 아니라 정말 무궁무진하게 간단히 구성할 수 있다는걸 느낄 것이다.)

추가로 있어야 하는 것들(이지만 당장 불가능... 공부도 해야되는데 ㅠ)

1. LDAP 연동

2. 다양한 상태 볼 수 있는 기능

3. DB 관리

4. 결재 연동

5. OTP 등록 가능하도록 구현

6. 웹 접근시 역할 구분(권한)

7. StartSession 권한 부여

등등등 갈 길은 멀고~~ 할건 많고 이래서 IT가 너무 재밌다.