이 가이드는 아이덴티티 인프라를 강화하고 IdP 취약점과 관련된 위험을 완화하는 데 도움을 줍니다.

IdP 침해는 공격자가 아이덴티티 관리 시스템에 무단으로 접근하여 합법적인 사용자를 가장하거나, 권한을 에스컬레이션하거나, 민감한 정보에 접근할 수 있게 될 때 발생합니다. 이는 소프트웨어 취약점 악용, 자격 증명 도용, 사회 공학 공격 등 다양한 방법으로 발생할 수 있습니다.

많은 조직에서 SSO(Single Sign-On) 및 MFA(Multi-Factor Authentication)와 같은 기본 보안 조치를 구현했지만, 이것만으로는 IdP를 대상으로 하는 정교한 공격으로부터 보호하기에 충분하지 않을 수 있습니다. 공격자들은 지속적으로 기술을 발전시키고 있으며, 기존 보안 조치에는 악용될 수 있는 한계나 취약점이 있을 수 있습니다.

IdP 침해에 대한 방어를 강화하기 위해 다음과 같은 포괄적인 보안 조치를 구현하는 것을 권장합니다.

클러스터 전반 WebAuthn 설정#

WebAuthn 표준을 사용하여 전체 인프라에 강력한 피싱 저항 인증을 구현합니다. W3C 표준이자 FIDO2의 일부인 WebAuthn은 웹 인증을 위한 공개 키 암호화를 사용합니다. Teleport는 Teleport에 로그인(tsh login 또는 Web UI를 통해)하고 SSH 노드 또는 Kubernetes 클러스터에 접근하기 위한 다중 요소로 WebAuthn을 지원합니다. YubiKey, SoloKey와 같은 하드웨어 키와 Touch ID, Windows Hello와 같은 생체 인증기와 호환됩니다.

사전 요구 사항#

• 실행 중인 Teleport 클러스터 또는 Teleport Cloud. Teleport를 시작하려면 무료 체험에 가입하세요.

• tctl 관리 도구와 tsh 클라이언트 도구.

  tctl과 tsh 다운로드 지침은 설치를 방문하세요.

• YubiKey 또는 SoloKey와 같은 WebAuthn 하드웨어 장치

• WebAuthn을 지원하는 웹 브라우저

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1/3단계. WebAuthn 지원 활성화#

WebAuthn 지원을 활성화하려면 아래와 같이 Teleport 구성을 업데이트하세요:

cluster_auth_preference 리소스를 편집합니다:

$ tctl edit cap

cluster_auth_preference 정의를 다음 내용을 포함하도록 업데이트합니다:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  type: local
  # WebAuthn 지원을 활성화하려면 "webauthn"을 두 번째 인수 방법으로 포함합니다.
  second_factors: ["webauthn"]
  webauthn:
    # 필수, 프록시 웹 주소로 교체합니다(example.com, example.teleport.sh).
    # rp_id는 Teleport Proxy Service의 공개 도메인으로, 프로토콜
    # (https://)과 포트 번호는 *제외*합니다.
    rp_id: example.com
    # 선택 사항, attestation_allowed_cas는 인증 기관의 선택적 허용 목록입니다.
    attestation_allowed_cas:
    # 항목은 인증서 파일의 경로일 수 있습니다:
    - "/path/to/allowed_ca.pem"
    # 항목은 인라인 인증서일 수도 있습니다:
    - |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    # 선택 사항, attestation_denied_cas는 인증 기관의 선택적 거부 목록입니다.
    attestation_denied_cas:
    # 항목은 인증서 파일의 경로일 수 있습니다:
    - "/path/to/denied_ca.pem"
    # 항목은 인라인 인증서일 수도 있습니다:
    - |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----

파일을 저장하고 종료합니다. tctl이 원격 정의를 업데이트합니다:

cluster auth preference has been updated

webauthn 필드 정의#

rp_id는 Teleport Proxy Service의 공개 도메인으로, 프로토콜(https://)과 포트 번호는 제외합니다.

attestation_allowed_cas는 장치 검증을 위한 인증 기관(로컬 파일 경로 또는 인라인 PEM 인증서 문자열)의 선택적 허용 목록입니다.

이 필드를 통해 신뢰하는 장치 모델과 제조업체를 제한할 수 있습니다. 목록 외부의 장치는 등록 시 거부됩니다. 기본적으로 모든 장치가 허용됩니다. 증명을 사용해야 하는 경우, 대신 attestation_denied_cas를 사용하여 문제가 있는 장치를 금지하는 것을 고려하세요.

attestation_denied_cas는 장치 검증을 위한 인증 기관(로컬 파일 경로 또는 인라인 PEM 인증서 문자열)의 선택적 거부 목록입니다.

이 필드를 통해 특정 장치 모델과 제조업체를 금지하면서 다른 장치들은 허용(attestation_allowed_cas도 통과하는 경우)할 수 있습니다. 이 목록에 있는 장치는 등록 시 거부됩니다. 기본적으로 금지된 장치는 없습니다.

2/3단계. 사용자로서 WebAuthn 장치 등록#

사용자는 tsh를 사용하여 여러 WebAuthn 장치를 등록할 수 있습니다:

$ tsh mfa add
# Choose device type [TOTP, WEBAUTHN]: webauthn
# Enter device name: desktop yubikey
# Tap any *registered* security key or enter a code from a *registered* OTP device:
# Tap your *new* security key
# MFA device "desktop yubikey" added.

3/3단계. WebAuthn으로 로그인#

WebAuthn 장치가 등록되면 사용자는 로그인 시 이를 요청받습니다:

$ tsh login --proxy=example.teleport.sh
# Enter password for Teleport user codingllama:
# Tap any security key or enter a code from a OTP device:
# > Profile URL:        https://example.teleport.sh
#   Logged in as:       codingllama
#   Cluster:            example.teleport.sh
#   Roles:              access, editor, reviewer
#   Logins:             codingllama
#   Kubernetes:         enabled
#   Valid until:        2021-10-04 23:32:29 -0700 PDT [valid for 12h0m0s]
#   Extensions:         permit-agent-forwarding, permit-port-forwarding, permit-pty

세션별 MFA 구성#

지속적인 보안을 유지하기 위해 초기 로그인 시뿐만 아니라 각 세션마다 다중 요소 인증이 요구되도록 합니다. Teleport의 세션별 MFA는 디스크에 저장된 인증서가 침해된 경우를 보호하여 보안을 강화합니다. 새로운 SSH, Kubernetes, 데이터베이스 또는 데스크톱 세션을 시작할 때 추가 MFA 확인이 필요합니다.

Teleport는 다음을 새로 시작할 때 추가 다중 요소 인증 확인을 요구하는 것을 지원합니다:

• SSH 연결(단일 tsh ssh 호출, Web UI SSH 세션 또는 Teleport Connect SSH 세션)
• Kubernetes 세션(단일 kubectl 호출)
• 데이터베이스 세션(단일 tsh db connect 호출 또는 단일 tsh proxy db --tunnel 실행)
• 애플리케이션 세션
• 데스크톱 세션

모든 역할에 대해 MFA 확인을 강제하려면 클러스터 인증 구성을 편집합니다:

cluster_auth_preference 리소스를 편집합니다:

$ tctl edit cap

리소스에 다음 내용이 포함되도록 합니다:

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  require_session_mfa: true
version: v2

편집기에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

역할별#

특정 역할에 대해 MFA 확인을 강제하려면 역할에 다음을 포함하도록 업데이트합니다:

kind: role
version: v7
metadata:
  name: example-role-with-mfa
spec:
  options:
    # 이 역할에 세션별 MFA 요구
    require_session_mfa: true
  allow:
    ...
  deny:
    ...

클러스터 전반 Device Trust 구현#

알 수 없거나 침해된 장치로부터의 무단 접근 위험을 줄이기 위해 조직 전반에서 신뢰할 수 있는 장치를 검증하고 관리하는 시스템을 개발합니다. Device Trust는 사용자 아이덴티티와 역할 적용을 보완하여 보호된 리소스에 접근하기 위해 신뢰할 수 있는 장치를 사용하도록 요구함으로써 추가 보안 계층을 추가합니다. 이는 클러스터 전반 또는 RBAC를 통해 구성할 수 있습니다. 지원되는 리소스에는 앱(역할 기반만), SSH 노드, 데이터베이스, Kubernetes 클러스터, 첫 번째 MFA 장치 등록이 포함됩니다. 마지막 항목은 침해된 IdP를 통한 새 사용자의 자동 프로비저닝을 방지하는 데 도움이 됩니다.

사전 요구 사항#

• To enroll a macOS device, you need:

  • A signed and notarized tsh binary. Download the macOS tsh installer.

• To enroll a Windows device, you need:

  • A device with TPM 2.0.
  • A user with administrator privileges. This is only required during enrollment.
  • The tsh client. Download the Windows tsh installer.

• To enroll a Linux device, you need:

  • A device with TPM 2.0.

  • A user with permissions to use the /dev/tpmrm0 device (typically done by assigning the tss group to the user).

  • The tsh client. Install tsh for Linux.

    WSL users should use the Windows binary instead. Download the Windows tsh installer.

• To authenticate a Web UI session you need Teleport Connect

• Correct end-user IP propagation to your Teleport deployment: X-Forwarded-For header (L7 load balancer) or PROXY protocol (L4 load balancer)

tctl 도구는 장치 인벤토리를 관리하는 데 사용됩니다. 장치 관리자는 장치를 관리하고, 새 장치를 인벤토리에 추가하고, 더 이상 사용하지 않는 장치를 제거할 책임이 있습니다.

$ tsh device enroll --current-device

1/3단계. 신뢰할 수 있는 장치 등록#

장치를 등록하기 전에 먼저 등록해야 합니다. 장치를 등록하려면 먼저 일련 번호를 확인해야 합니다.

tsh로 장치 일련 번호를 가져옵니다(등록하려는 장치에서 실행해야 함):

$ tsh device asset-tag
(=devicetrust.asset_tag=)

$ tsh device asset-tag
(=devicetrust.asset_tag=)

[devicetrust.asset_tag]" description="등록할 일련 번호"/>를 등록하려는 장치의 일련 번호로 교체하고, 를 운영 체제로 교체합니다. tctl devices add 명령을 실행합니다:

$ tctl devices add --os='' --asset-tag=''
Device /macos added to the inventory

tctl을 사용하여 장치가 등록되었는지 확인합니다:

$ tctl devices ls
Asset Tag    OS    Source Enroll Status Owner Device ID
------------ ----- ------ ------------- ----- ------------------------------------
(=devicetrust.asset_tag=) macOS        not enrolled        (=devicetrust.device_id=)

2/3단계. 장치 등록 토큰 생성#

등록된 장치는 등록 절차를 거친 후 신뢰할 수 있는 장치가 됩니다. 장치를 등록하려면 장치 등록 토큰이 필요합니다. 토큰은 장치 관리자가 생성하고 등록을 수행하는 사람에게 오프밴드(예: 회사 채팅)로 전송합니다.

등록 토큰을 생성하려면 아래 명령을 실행합니다. 여기서 --asset-tag는 등록하려는 장치의 일련 번호입니다:

$ tctl devices enroll --asset-tag="(=devicetrust.asset_tag=)"
Run the command below on device "(=devicetrust.asset_tag=)" to enroll it:
tsh device enroll --token=(=devicetrust.enroll_token=)

3/3단계. 신뢰할 수 있는 장치 등록#

등록 절차를 수행하려면 위에 지정된 장치를 사용하여 tctl devices enroll이 출력한 명령을 입력합니다:

$ tsh device enroll --token=(=devicetrust.enroll_token=)
Device "(=devicetrust.asset_tag=)"/macOS enrolled

$ tsh logout
$ tsh login --proxy=(=clusterDefaults.clusterName=) --user=(=clusterDefaults.username=) # fetch new certificates
Enter password for Teleport user (=clusterDefaults.username=):
Tap any security key
Detected security key tap
> Profile URL:        (=clusterDefaults.clusterName=):443
  Logged in as:       (=clusterDefaults.username=)
  Cluster:            (=clusterDefaults.clusterName=)
  Roles:              access, editor
  Logins:             (=clusterDefaults.username=)
  Kubernetes:         enabled
  Valid until:        2023-06-23 02:47:05 -0300 -03 [valid for 12h0m0s]
  Extensions:         teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id

teleport-device-* 확장 기능의 존재는 장치가 성공적으로 등록되고 인증되었음을 나타냅니다. 이제 위의 장치가 신뢰할 수 있는 장치입니다.

자동 등록#

많은 사용자에게 등록 토큰을 배포하는 것은 어려울 수 있습니다. 이를 해결하기 위해 Teleport는 자동 등록을 지원합니다. 활성화되면 자동 등록은 다음 Teleport(tsh) 로그인 시 사용자의 장치를 자동으로 등록합니다.

자동 등록이 작동하려면 다음 조건이 충족되어야 합니다:

• 장치가 등록되어 있어야 합니다. 등록은 수동으로 수행하거나 MDM 연동을 사용하여 수행할 수 있습니다.
• 클러스터 설정에서 자동 등록이 활성화되어 있어야 합니다.

1/2단계. 클러스터 설정에서 자동 등록 활성화#

tctl edit cluster_auth_preference를 사용하여 동적 구성 리소스를 수정합니다:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  # ...
  device_trust:
    mode: "required"
+   auto_enroll: true

2/2단계. 로그아웃 후 다시 로그인#

활성화되면 Teleport에 장치가 등록된 사용자는 다음 로그인 시 장치가 Teleport에 등록됩니다.

$ tsh logout
All users logged out.
$ tsh login --proxy=(=clusterDefaults.clusterName=) --user=(=clusterDefaults.username=)
Enter password for Teleport user (=clusterDefaults.username=):
Tap any security key
Detected security key tap
> Profile URL:        (=clusterDefaults.clusterName=):443
  Logged in as:       (=clusterDefaults.username=)
  Cluster:            (=clusterDefaults.clusterName=)
  Roles:              access, editor
  Logins:             (=clusterDefaults.username=)
  Kubernetes:         enabled
  Valid until:        2023-06-23 02:47:05 -0300 -03 [valid for 12h0m0s]
  Extensions:         teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id

teleport-device-* 확장 기능의 존재는 장치가 성공적으로 등록되고 인증되었음을 나타냅니다.

관리 작업에 MFA 요구#

높은 권한이 필요한 작업에 대해 다중 요소 인증을 요구하여 민감한 관리 작업에 추가 보안 계층을 추가합니다. Teleport는 모든 클라이언트(tctl, tsh, Web UI, Connect)에서 관리 작업에 대한 추가 MFA 검증을 시행합니다. 이 기능은 관리 작업 직전에 사용자 아이덴티티를 즉시 재검증하여 침해된 관리자 계정으로 인한 위험을 완화하는 추가 보안 계층을 추가합니다.

이러한 고급 보안 조치를 채택함으로써 IdP 침해에 대한 강력한 방어를 구축하고 조직의 공격 표면을 크게 줄일 수 있습니다. 다음 섹션에서는 이러한 각 권장 사항을 더 자세히 살펴보고, 구현 및 모범 사례에 대한 단계별 지침을 제공합니다.

사전 요구 사항#

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

• 이 클러스터에 WebAuthn이 구성되어 있어야 합니다.
• YubiKey 또는 SoloKey와 같은 다중 요소 하드웨어 장치
• WebAuthn을 지원하는 웹 브라우저(Teleport Web UI에서 SSH 또는 데스크톱 세션을 사용하는 경우).

관리 작업에 대한 MFA는 WebAuthn만 다중 요소로 허용하는 클러스터에 자동으로 시행됩니다.

관리 작업의 예시에는 다음이 포함되지만 이에 국한되지 않습니다:

• 사용자 계정 재설정 또는 복구
• 새 사용자 초대
• 클러스터 구성 리소스 업데이트
• 접근 관리 리소스 수정
• 접근 요청 승인
• 새 조인 토큰 생성
• 가장
• 머신 및 워크로드 아이덴티티를 위한 새 봇 생성

이것은 디스크에 저장된 Teleport 인증서의 침해로부터 사용자를 보호하는 고급 보안 기능입니다.

1/2단계. 리소스 편집#

cluster_auth_preference 리소스를 편집합니다:

$ tctl edit cap

cluster_auth_preference 정의를 다음 내용을 포함하도록 업데이트합니다:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  type: local
  second_factors: ["webauthn"]
  webauthn:
    rp_id: example.com

2/2단계. 파일 저장 및 종료#

tctl 명령이 원격 정의를 업데이트합니다:

cluster auth preference has been updated

다음 단계#

추가 클러스터 강화 조치는 다음을 참조하세요:

• 패스워드 없는 인증: 패스워드 및 사용자 이름 없는 인증을 제공합니다.
• 잠금: 활성 사용자 세션 또는 호스트에 대한 접근을 잠급니다.
• 중재 세션: 세션 감사자를 요구하고 세밀한 실시간 세션 접근을 허용합니다.
• 하드웨어 키 지원: 하드웨어 기반 개인 키 사용을 강제합니다.
• MFA 확인을 위한 SSO 구성: 세션별 MFA를 IdP에 위임합니다.