SSH 로그인 액세스 제어 권장사항

이 문서에서는 Linux 가상 머신(VM) 인스턴스에 대한 SSH 로그인 액세스를 제어하기 위한 권장사항을 설명합니다.

VM 인스턴스에 대한 SSH 액세스를 효과적으로 관리하려면 사용자에게 필요할 때 액세스를 허용하고 더 이상 필요하지 않을 때 액세스 권한을 취소해야 합니다. 액세스 권한을 취소하는 프로세스가 안정적이지 않거나 일부 리소스를 다루지 않는 경우 악의적인 행위자가 액세스 권한이 취소된 후에도 액세스 권한을 보유할 수 있습니다.

다음 섹션에는 효과적인 액세스 권한 취소를 보장하고 지속성 위협으로부터 보호하는 데 도움이 되는 권장사항이 포함되어 있습니다.

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

OS 로그인을 사용하여 IAM 정책에 대한 지속적인 액세스 평가 수행

Compute Engine 공개 Linux 이미지는 SSH 공개 키 인증을 허용하도록 구성됩니다. 사용자의 공개 키를 승인하고 SSH 세션을 설정할 수 있는 권한을 부여하려면 다음 두 가지 메커니즘 중 하나를 사용하면 됩니다.

  • 메타데이터 기반 키 승인: 관리자가 사용자의 공개 키를 VM 또는 프로젝트 메타데이터에 업로드하거나 사용자에게 메타데이터 수정 권한을 부여하여 사용자가 직접 업로드를 수행하도록 할 수 있습니다.

    단일 VM의 메타데이터에 업로드된 공개 키는 사용자에게 해당 VM에 대해서만 사용자 루트 권한을 부여하고, 프로젝트 메타데이터에 업로드된 키는 프로젝트의 모든 VM에 대한 사용자 액세스 권한을 부여합니다.

  • OS 로그인 키 승인: 사용자는 Google 사용자 계정의 일부인 OS 로그인 프로필에 하나 이상의 공개 키를 업로드합니다.

    관리자는 OS 로그인 관리자 IAM 역할 또는 OS 로그인 사용자 IAM 역할을 부여하여 VM에 대한 사용자 루트 권한 또는 일반 사용자 권한을 부여할지 여부를 결정할 수 있습니다.

    gcloud CLI, Google Cloud 콘솔 브라우저 내 SSH 클라이언트, IAP 데스크톱은 사용 중인 메커니즘을 자동으로 감지하여 그에 따라 사용자의 키를 업로드할 수 있습니다.

두 메커니즘의 주요 차이점은 IAM 정책에 따라 액세스가 평가되는 경우입니다.

  • 메타데이터 키를 사용하면 키 업로드 시 액세스가 한 번만 평가됩니다.

    사용자의 키는 VM 또는 프로젝트의 수명 주기에 연결되며 키를 삭제하거나 VM 또는 프로젝트를 삭제할 때까지 유효합니다. 사용자 계정을 정지하거나 삭제해도 키 유효성에는 영향을 주지 않습니다.

  • OS 로그인을 사용하면 사용자가 SSH 세션을 설정하려고 시도할 때마다 액세스 권한이 평가됩니다.

    사용자의 키는 사용자 계정의 수명 주기에 연결됩니다. Cloud ID 또는 Google Workspace에서 사용자를 정지하거나 삭제하면 해당 키를 더 이상 SSH 액세스 권한을 부여하는 데 사용할 수 없습니다.

메타데이터 기반 키를 사용하면 지속성 위협에 노출될 수 있습니다. 메타데이터에서 공개 키를 적시에 제거하지 않으면 사용자가 필요 이상으로 길게 SSH 액세스 권한을 유지하고, 경우에 따라 퇴사 후에도 액세스 권한을 유지할 수 있습니다. 메타데이터를 정기적으로 검사하여 이 위험을 줄일 수 있지만 대규모 환경에서는 메타데이터 기반 키에서 사용자에게 루트 권한을 부여하므로 이러한 작업이 어려울 수 있습니다.

이러한 지속성 위협으로부터 보호하려면 사용자가 메타데이터 기반 키를 사용하도록 허용하지 마세요. 대신 OS 로그인 사용을 적용하도록 프로젝트를 구성합니다.

조직 정책을 사용하여 OS 로그인의 일관된 사용 적용

OS 로그인이 enable-oslogin 메타데이터 키로 제어됨: 프로젝트 또는 인스턴스 메타데이터에서 enable-oslogin을 TRUE로 설정하면 OS 로그인이 활성화되고, FALSE로 설정하면 OS 로그인이 비활성화됩니다.

프로젝트 수준 메타데이터를 수정하려면 프로젝트에 대한 compute.projects.setCommonInstanceMetadata 권한이 필요합니다. 이 권한은 Compute 인스턴스 관리자(roles/compute.instanceAdmin.v1) 및 Compute 관리자(roles/compute.admin) 역할의 일부입니다. 마찬가지로 인스턴스 수준 메타데이터를 수정하려면 각 VM 인스턴스에 대한 compute.instances.setMetadata 권한이 필요합니다.

인스턴스 수준의 메타데이터는 프로젝트 수준의 메타데이터보다 우선 적용됩니다. 따라서 프로젝트 메타데이터에서 enable-oslogin을 TRUE로 설정하는 것으로는 프로젝트 전체에서 OS 로그인을 사용하도록 강제하기에 충분하지 않습니다. Compute 인스턴스 관리자 또는 프로젝트의 VM 인스턴스에 대한 동등한 액세스 권한이 있는 사용자는 VM 인스턴스의 메타데이터에 enable-oslogin=FALSE를 추가하여 설정을 재정의할 수 있습니다.

OS 로그인을 일관되게 사용하려면 프로젝트 메타데이터에서 enable-oslogin을 TRUE로 설정하지 마세요. 대신 조직 정책을 사용하는 조직에 OS 로그인 사용 설정을 적용하여 인스턴스 또는 프로젝트 메타데이터에서 enable-oslogin을 false로 설정하려는 시도가 거부되도록 합니다.

임시 또는 VM별로 권한이 있는 역할 부여

서로 다른 워크로드를 실행하고 서로 다른 팀에서 관리하는 VM 인스턴스가 있는 경우 이러한 VM을 여러 Google Cloud 프로젝트에 배포하고 프로젝트에서 공유 네트워크를 사용하도록 허용하여 액세스 관리를 간소화할 수 있습니다. 하지만 개별 프로젝트를 사용하는 것이 항상 가능한 것은 아니며, 일부 프로젝트에는 VM 인스턴스에 서로 다른 사용자만 액세스할 수 있는 VM 인스턴스 조합이 포함될 수 있습니다.

프로젝트에 이러한 다양한 VM 인스턴스 조합이 포함되어 있는 경우 프로젝트 수준에서 사용자에게 Compute 인스턴스 관리자와 같은 역할을 영구적으로 부여하지 마세요. 대신 보기 전용 액세스와 권한 있는 액세스를 구분합니다.

  • 사용자에게 프로젝트 수준의 Compute 뷰어 또는 이에 상응하는 보기 전용 역할을 부여합니다. 이 역할로 사용자는 Google Cloud 콘솔을 사용하여 VM을 탐색할 수 있지만 SSH 키를 게시하거나 VM에 액세스할 수는 없습니다.
  • 사용자에게 Compute OS 로그인, Compute 인스턴스 관리자 또는 기타 권한이 있는 역할을 개별 VM에만 부여하거나 적시에만 부여합니다.

사용자가 조직을 탈퇴할 때 사용자 계정 정지

Cloud ID 또는 Google Workspace에서 사용자 계정을 정지하거나 삭제하면 사용자의 IAM 권한이 자동으로 취소됩니다. OS 로그인은 사용자가 SSH 세션을 설정하도록 허용하기 전에 사용자의 IAM 권한을 확인하기 때문에 사용자 계정을 정지하거나 삭제하면 OS 로그인을 사용하는 VM에 대한 사용자의 액세스 권한도 취소됩니다.

싱글 사인온에 외부 IdP를 사용하도록 Cloud ID 또는 Google Workspace를 구성한 경우 직원은 외부 IdP와 Cloud ID 또는 Google Workspace 모두에 사용자 계정을 보유하게 됩니다. 외부 IdP에서 직원의 사용자 계정을 사용 중지하거나 삭제하면 Google 서비스에 액세스하기 위해 새 브라우저 세션을 설정하는 기능이 취소되지만 OS 로그인에는 즉각적인 영향을 미치지 않음: 직원의 Cloud ID 또는 Google Workspace 사용자 계정이 활성 상태로 유지되는 한 OS 로그인은 사용자가 계속 인증하고 SSH 연결을 설정할 수 있도록 허용합니다.

사용자가 조직에서 퇴사할 때 SSH 액세스 권한을 안정적으로 취소하려면 해당 Cloud ID 또는 Google Workspace 사용자 계정을 정지하거나 삭제해야 합니다. 외부 IdP를 사용하는 경우 OS 로그인이 액세스 권한을 취소할 수 있도록 사용자 정지 이벤트를 전파하도록 구성합니다.

권한이 있는 서비스 계정이 있는 VM에 SSH 액세스 권한을 부여하지 않음

VM 인스턴스에 연결된 서비스 계정이 있는 경우 VM에서 실행되는 애플리케이션은 VM의 메타데이터 서버에서 단기 사용자 인증 정보를 요청하고 이 사용자 인증 정보를 사용하여 서비스 계정으로 작동할 수 있습니다.

VM에 SSH 액세스 권한이 있으면 유사한 권한이 부여됨: 애플리케이션과 마찬가지로 VM의 메타데이터 서버에서 단기 사용자 인증 정보를 요청하고 연결된 서비스 계정으로 작동할 수 있습니다.

연결된 서비스 계정이 있는 VM에 대한 SSH 액세스 권한이 있으면 서비스 계정으로 작업할 수 있으므로 OS 로그인에는 서비스 계정에 대한 iam.serviceAccounts.actAs 권한이 필요하며 VM 인스턴스에 연결할 때마다 이 권한을 확인합니다. 이렇게 하면 OS 로그인이 서비스 계정의 보안을 유지하고 권한 에스컬레이션에 SSH 액세스가 악용되는 것을 방지하는 데 도움이 됩니다.

권한 있는 서비스 계정이 있는 VM과 관련된 위험을 추가로 완화하려면 다음 대안을 고려하세요.

  • 워크로드에 Google Cloud 리소스에 대한 액세스가 필요한 경우가 아니라면 VM에 서비스 계정을 연결하지 마세요.
  • 단일 목적 서비스 계정을 사용하고 워크로드에 필요한 리소스에 대한 액세스 권한만 부여합니다.
  • 사용자에게 VM 및 서비스 계정에 대한 액세스 권한을 영구적으로 부여하는 대신 적시 액세스를 요청하도록 요구합니다.

루트 권한 사용 제한

OS 로그인을 사용하고 사용자에게 OS 로그인 사용자(roles/compute.osLogin) 역할을 부여하면 사용자에게 VM에 대한 제한된 사용자 권한이 할당됩니다. 반면 사용자에게 OS 로그인 관리자(roles/compute.osAdminLogin) 역할을 부여하면 OS 로그인 대신 메타데이터 기반 키 승인을 사용하거나 사용자가 VM 메타데이터를 수정하도록 허용하는 경우 사용자에게 VM에 대한 루트 권한을 암시적으로 부여합니다.

사용자에게 VM에 대한 루트 권한을 부여하면 지속성 위험에 노출될 수 있음: 사용자가 이러한 권한을 악용하여 새 사용자 계정을 만들거나 백도어를 설치하여 VM에 대한 지속적인 액세스 권한을 유지할 수 있습니다.

이러한 지속성 위험을 줄이려면 루트 권한 사용을 제한하고 루트 권한이 필요하지 않은 경우에만 OS 로그인 사용자(roles/compute.osLogin) 역할을 부여하세요.

POSIX 프로필을 미리 생성하여 일관된 사용자 이름 및 UID 보장

각 Linux VM은 사용자(/etc/passwd) 및 그룹(/etc/groups)의 로컬 데이터베이스를 유지합니다. SSH를 사용하여 Linux VM에 처음 연결하면 게스트 환경에서 자동으로 Linux 사용자 계정을 생성하고 UID를 할당합니다.

메타데이터 기반 키를 사용하는 경우 게스트 환경에서는 Linux 사용자를 Google 사용자 계정에 연결하지 않으며 연결하는 각 VM에 다른 UID를 할당할 수 있습니다. 머신 간에 일관된 UID를 적용하지 않는 환경에서 일관된 UID를 가정하는 NFS와 같은 프로토콜을 사용하면 사용자가 실수로 또는 악의적인 행위자의 경우 의도적으로 다른 사용자로 원격 액세스를 수행할 수 있습니다.

메타데이터 기반 키를 사용하는 경우 게스트 환경에서 사용할 사용자 이름을 선택할 수도 있습니다. 동료가 이전에 사용한 사용자 이름을 선택하면 동료가 처음에 만든 계정으로 로그인하게 됩니다.

OS 로그인을 사용하면 이러한 UID 및 사용자 이름 모호성을 방지할 수 있음: OS 로그인을 사용하여 Linux VM에 처음 로그인하면 게스트 환경에서 Google 사용자 계정의 POSIX 프로필을 기반으로 Linux 사용자를 만듭니다. POSIX 프로필은 Linux 사용자를 위한 템플릿 역할을 하며 다음을 정의합니다.

  • 동일한 Cloud ID 또는 Google Workspace 계정의 모든 사용자 간에 고유한 Linux 사용자 이름
  • 모든 Google Cloud 프로젝트에서 고유한 UID 및 GID
  • 홈 디렉터리 경로
  • 추가 구성(예: 로그인 셸)

처음 로그인할 때 Google 계정에 POSIX 프로필이 없으면 OS 로그인에서 자동으로 프로필을 만듭니다.

OS 로그인에서 할당된 사용자 이름 및 UID는 Google Cloud 환경 내에서 고유하지만 Google Cloud 외부에서 사용하는 사용자 이름 및 UID와 겹치거나 일치하지 않을 수 있습니다. 다른 환경에서 OS 로그인 사용자 이름과 UID를 일관되게 유지해야 하는 경우에는 자동 프로필 생성을 사용하지 않는 것이 가장 좋습니다. 대신 Directory API를 사용하여 OS 로그인 POSIX 프로필을 미리 만들고 맞춤 사용자 이름, UID, GID를 할당합니다.

다음 단계