SSH 사용자 인증 정보 보호를 위한 권장사항

이 문서에서는 SSH 사용자 인증 정보를 보호하기 위한 권장사항을 설명합니다.

기본적으로 Compute Engine은 공개 키 기반 SSH 인증을 사용합니다. 사용자는 SSH 비공개 키라는 소유한 항목으로 인증됩니다. 사용자의 비공개 키가 제대로 보호되지 않으면 악의적인 행위자가 이러한 키를 사용하여 VM 인스턴스에 액세스할 수 있습니다.

다음 섹션에는 키 유출을 방지하고 유출된 비공개 키의 잠재적 영향을 줄이는 데 도움이 되는 권장사항이 포함되어 있습니다.

이 문서는 Google Cloud에 한정된 관행이나 Google Cloud에서 SSH를 사용할 때 특별한 관련성이 있는 관행을 집중적으로 설명합니다. 이 문서에서는 특정 SSH 클라이언트 또는 서버 구현을 위한 권장사항을 설명하지 않습니다.

SSH 비공개 키를 서비스 계정 키와 유사하게 취급

일부 VM 인스턴스에는 연결된 서비스 계정이 있을 수 있습니다. VM에 서비스 계정을 연결하면 이러한 VM에서 실행되는 워크로드가 Google Cloud API 및 리소스에 액세스할 수 있도록 메타데이터 서버에서 단기 액세스 토큰을 요청할 수 있습니다.

SSH를 통해 연결된 서비스 계정이 있는 VM에 연결할 때 메타데이터 서버에서 단기 액세스 토큰을 요청할 수도 있습니다. 따라서 사용자에게 VM에 대한 SSH 액세스 권한을 부여하는 것은 사용자에게 연결된 서비스 계정으로 작업할 수 있는 권한을 부여하는 것과 유사합니다. 이러한 유사성으로 인해 SSH 비공개 키, 특히 암호로 보호되지 않는 경우에는 서비스 계정 키처럼 취급합니다. 두 가지 유형의 키가 유출되면 악의적인 행위자에게 Google Cloud 리소스에 액세스할 수 있는 권한이 부여될 수 있습니다.

머신 사용자를 위한 임시 SSH 키 사용

배포를 수행하거나 구성 변경사항을 적용하려면 배포 파이프라인 또는 자동화 프로세스에 VM 인스턴스에 대한 SSH 액세스 권한이 필요할 수 있습니다. 이러한 워크로드에서 장기 SSH 키 쌍을 사용하는 대신 실행할 때마다 새 임시 SSH 키를 사용하도록 합니다.

임시 SSH 키를 사용하려면 배포 파이프라인 또는 자동화 프로세스에서 다음 단계를 수행하도록 합니다.

  1. 키나 보안 비밀이 포함되지 않는 방식(예: 연결된 서비스 계정 또는 워크로드 아이덴티티 제휴 사용)을 사용하여 서비스 계정으로 인증합니다.
  2. ssh-keygen과 같은 도구를 사용하여 임시 SSH 키 쌍을 생성합니다.

  3. 가까운 만료일(예: 1시간 후)을 지정하여 공개 키를 Google Cloud에 게시합니다.

    OS 로그인을 사용하면 키를 게시할 때 키 만료일을 지정할 수 있습니다. 마찬가지로 SSH 공개 키를 프로젝트나 VM 메타데이터에 게시할 때 만료일을 지정할 수 있습니다.

  4. 비공개 키를 사용하여 VM 인스턴스에 대한 SSH 연결을 설정합니다.

  5. 원하는 경우 공개 키를 게시 취소하고 비공개 키를 삭제합니다.

예를 들면 다음과 같습니다.

# Generate RSA2048 key pair without passphrase
ssh-keygen -b 2048 -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

임시 SSH 비공개 키가 여전히 유출될 수 있지만 짧은 시간 동안만 사용될 수 있습니다. 따라서 임시 SSH 키를 사용하면 사용자 인증 정보 유출 위험이 줄어들 수 있으며 Cloud IAM을 기본 인증 및 승인 수단으로 사용할 수 있습니다.

IAP를 사용하여 SSH 공개 키 인증 보완

기본적으로 SSH 비공개 키를 Google 사용자 인증 정보와 별개로 사용할 수 있습니다. 사용자의 비공개 SSH 키가 유출되면 악의적인 행위자가 이 키를 사용하여 키에 액세스 권한이 있는 VM 인스턴스에 연결하고 인증할 수 있습니다. 악의적인 행위자가 사용자의 사용자 이름이나 비밀번호를 알거나 Google 사용자 인증 정보를 소유할 필요도 없습니다.

2단계 인증 및 Google Cloud 서비스의 세션 길이 제한과 같은 보안 제어는 사용자 인증 정보 도용 위험을 줄이는 효과적인 방법이 될 수 있지만 이러한 제어는 Google 사용자 인증 정보가 필요한 리소스에만 적용됩니다.

유효한 Google 사용자 인증 정보가 없으면 SSH 키를 사용할 수 없게 하려면 IAP를 사용하여 SSH 액세스를 관리하고 방화벽 정책을 사용하여 모든 SSH 액세스가 IAP를 통해 수행되도록 합니다.

IAP는 리버스 프록시로 작동하며 사용자가 자신의 Google 사용자 인증 정보를 통해 성공적으로 인증된 경우에만 VM 인스턴스에 SSH 연결을 설정하도록 허용합니다. 또한 IAP를 사용하면 사용자가 연결할 수 있는 VM을 제한하고 컨텍스트 인식 액세스를 적용할 수 있습니다.

다단계 인증 사용

IAP를 사용하여 SSH 액세스를 관리하면 악의적인 행위자가 유출된 사용자 인증 정보를 사용하여 VM 인스턴스에 액세스하기가 더 어려워지지만 불가능하지는 않습니다. 예를 들어 악의적인 행위자가 워크스테이션을 손상시켜 비공개 SSH 키와 캐시된 gcloud CLI 사용자 인증 정보를 모두 찾을 수 있습니다. 이 정도면 IAP의 인증 및 승인 검사를 통과하고 사용자의 VM 인스턴스에 연결할 수 있습니다.

다중 인증(MFA)이 필요하도록 Cloud ID 또는 Google Workspace를 구성하면 이러한 사용자 인증 정보 도용 공격의 영향력을 줄일 수 있습니다.

Cloud ID 또는 Google Workspace가 기본 ID 공급업체이면 다음과 같이 MFA를 적용합니다.

  1. 2단계 인증을 적용하도록 Cloud ID 또는 Google Workspace를 구성합니다.
  2. 캐시된 사용자 인증 정보가 자동으로 무효화되고 사용자가 주기적으로 재인증하고 MFA를 수행해야 하도록 Google Cloud 서비스 세션 길이를 제한합니다.

외부 IdP와 함께 싱글 사인온을 사용하는 경우에는 대신 다음을 수행합니다.

  1. Google Cloud 서비스 세션 길이를 제한하도록 Cloud ID 또는 Google Workspace를 구성하여 캐시된 사용자 인증 정보가 자동으로 무효화되고 사용자가 주기적으로 외부 IdP를 사용하여 재인증해야 하도록 합니다.
  2. MFA를 요구하도록 외부 IdP를 구성하고 사용자가 Google Cloud 세션이 만료될 때마다 MFA를 수행해야 하도록 세션 길이를 제한합니다.

SSH 액세스에도 MFA를 적용하려면 최소한 다음 중 하나를 수행해야 합니다.

  1. 사용자가 주기적으로 MFA를 수행하여 Google 사용자 인증 정보를 새로고침해야 하도록 IAP를 사용하여 네트워크 액세스를 제어합니다.
  2. 사용자가 SSH 연결을 설정할 때마다 MFA를 수행해야 하도록 개별 VM 인스턴스나 전체 프로젝트에 OS 로그인 2FA를 사용 설정합니다.

VM 인스턴스나 프로젝트에 대한 Compute 인스턴스 관리자 또는 동등한 역할이 있는 사용자는 인스턴스 메타데이터를 수정하여 OS 로그인 2FA를 중지할 수 있습니다. 따라서 Cloud ID 또는 외부 IdP에서도 MFA를 적용하지 않으면 OS 로그인 2FA 효력이 제한됩니다.

내보낼 수 없거나 암호로 보호된 비공개 키 사용

많은 SSH 클라이언트에서 기본적으로 SSH 비공개 키를 디스크에 파일로 저장합니다. 예를 들어 gcloud compute ssh는 처음 사용할 때 SSH 키 쌍을 생성하고 홈 디렉터리에 저장합니다. 운영체제는 다른 사용자가 파일에 액세스하지 못하도록 파일을 보호할 수 있지만 악의적인 행위자가 파일 시스템 권한을 극복할 수 있는 경우(예: 다른 머신에 디스크 복사 및 마운트) 사용자가 모르게 키를 다른 곳에 복사하여 사용할 수 있습니다.

일부 SSH 클라이언트를 사용하면 파일 기반 키 사용을 방지하고 다음과 같은 SSH 비공개 키를 관리하는 대체 옵션을 제공할 수 있습니다.

  • 하드웨어 지원 키 사용: 최신 버전의 OpenSSH를 사용하면 인증에 FIDO2 보안 키를 사용할 수 있으며 Cloud ID 또는 Google Workspace에 등록된 보안 키만 허용하도록 OS 로그인을 구성할 수 있습니다. 하드웨어 지원 키를 사용하면 컴퓨터 파일 시스템에 비공개 키 자료를 저장하지 않아도 됩니다.
  • 운영체제의 키 스토리지 시설 사용: 예를 들어 IAP 데스크톱은 파일 기반 키를 사용하지 않고 대신 Windows CNG를 사용하여 SSH 키를 보호합니다.

하드웨어 지원 키나 운영체제 관리형 키를 사용할 수 없는 경우 암호를 사용하여 SSH 비공개 키를 보호할 수 있습니다. 악의적인 행위자가 암호로 보호된 SSH 키를 사용하려면 비공개 키 사본이 있어야 할 뿐만 아니라 키 암호도 알아야 합니다.

호스트 키를 사용하여 호스트 인증

VM 인스턴스에 대한 SSH 연결을 만들 때는 이름 또는 IP 주소별로 VM 인스턴스를 식별합니다. 이름과 IP 주소를 다시 할당하고 재사용할 수 있으며 어제의 특정 VM 인스턴스를 참조한 이름이 현재의 같은 VM 인스턴스를 참조하지 않을 수 있습니다. 악의적인 행위자는 VM 인스턴스를 스푸핑하기 위해 의도적으로 이름이나 IP 주소를 재할당하거나 재사용하여 사용자가 손상된 VM에 연결하도록 유도할 수 있습니다.

SSH 클라이언트는 SSH 호스트 키를 사용하여 이전에 신뢰할 수 있었던 VM 인스턴스가 다른 VM 인스턴스로 대체된 상황을 감지할 수 있습니다. VM의 SSH 호스트 키는 첫 부팅 시 생성되며 인스턴스를 식별하는 데 사용됩니다. SSH 클라이언트는 일반적으로 첫 번째 연결에서 VM의 호스트 키를 요청 및 저장하고 이후 연결에서 VM의 호스트 키가 변경되지 않았는지 확인합니다.

SSH 호스트 키는 처음 사용 시 신뢰 스킴을 기반으로 작동합니다. 악의적인 행위자가 중간자(MITM) 공격을 통해 클라이언트에서 첫 사용 시에 잘못된 VM에 연결하고 신뢰할 수 있게 하면 SSH 호스트 키 효과가 저하될 수 있습니다. 호스트 키를 가져오는 더 좋은 방법은 VM에 처음 연결하기 전에 신뢰할 수 있는 측 채널을 통해 호스트 키를 가져오는 것입니다.

프로젝트에서 게스트 속성을 사용 설정하여 백 채널을 통해 호스트 키를 가져오도록 gcloud CLI를 설정할 수 있습니다. 그러면 VM에 처음 연결하기 전에 gcloud CLI에서 VM 호스트 키를 읽고 로컬 컴퓨터에 저장합니다.

VM에 개인 사용자 인증 정보를 남겨 두면 안 됨

gcloud CLI를 승인하면 도구에서 OAuth 갱신 토큰을 가져와 로컬 홈 디렉터리에 저장합니다. 이후에 gcloud CLI 명령어를 실행하면 gcloud CLI에서 갱신 토큰을 사용하여 자동으로 인증합니다.

다른 사용자가 로컬 컴퓨터에 액세스하지 못할 수도 있지만 VM 인스턴스에서는 VM에 대한 sudo 권한이 있는 다른 사용자가 홈 디렉터리에 액세스할 수도 있습니다.

악의적인 행위자가 VM에 대한 sudo 권한을 가져오도록 관리하면 다른 사용자의 홈 디렉터리에서 갱신 토큰과 기타 사용자 인증 정보를 스캔하고 이러한 사용자 인증 정보를 사용하여 권한을 에스컬레이션하거나 액세스를 다른 리소스로 확장(측면 이동)할 수 있습니다.

SSH를 통해 VM 인스턴스에 연결하면 개인 사용자 인증 정보로 gcloud CLI 또는 애플리케이션 기본 사용자 인증 정보(ADC)를 승인하지 마세요. 대신 gcloud CLI에서 VM의 연결된 서비스 계정을 사용하도록 합니다. 마찬가지로 홈 디렉터리에 개인 사용자 인증 정보를 저장할 수 있는 다른 도구도 실행하지 마세요.

저장된 OAuth 갱신 토큰이 일정 시간 후에 자동으로 만료되도록 Google Cloud 서비스 세션 길이를 제한하여 위험을 더욱 줄일 수 있습니다.

소스 코드 저장소에 SSH 비공개 키를 제출하면 안 됨

Ansible과 같은 일부 자동화 도구는 SSH를 사용하여 VM 인스턴스에 액세스하고 관리합니다. 이러한 도구는 여러 VM 인스턴스(및 연결된 서비스 계정)에 액세스할 수 있으므로 이러한 도구에서 사용하는 SSH 비공개 키는 특히 민감할 수 있습니다.

SSH 비공개 키를 소스 코드 저장소에 제출하면 승인되지 않은 사용자와 악의적인 행위자가 키에 액세스할 수 있는 위험이 증가합니다.

  • 악의적인 사용자는 공개 소스 저장소의 소스 코드에서 유출된 키를 스캔할 수 있습니다.
  • 이후에 먼저 키를 확인하지 않고 비공개 소스 저장소를 공개 저장소로 전환할 수도 있습니다.
  • 다른 팀 멤버가 소스 코드의 복사본을 자신의 워크스테이션에 저장할 수 있습니다.

이러한 위험을 완화하려면 SSH 비공개 키를 소스 코드와 분리된 안전한 위치에 저장하고 가능하면 임시 SSH 키를 사용합니다.

다음 단계