IdP 침해에 대비하여 클러스터 강화 | Teleport 공식 기술 문서 한국판 by 인포그랩

IdP 침해에 대비하여 클러스터 강화

이 가이드는 여러분의 아이덴티티 인프라를 강화하고 IdP 취약성과 관련된 위험을 완화하는 데 도움을 주기 위해 작성되었습니다.

IdP가 침해된다는 것은 공격자가 여러분의 아이덴티티 관리 시스템에 무단으로 접근하여, 합법적인 사용자를 가장하거나 권한을 상승시키거나 민감한 정보에 접근할 수 있는 가능성이 있다는 것을 의미합니다. 이는 소프트웨어 취약점을 악용하거나 자격 증명을 도용하거나 사회 공학 공격을 통해 발생할 수 있습니다.

많은 조직이 싱글 사인온(SSO) 및 다단계 인증(MFA)과 같은 기본 보안 조치를 구현했지만, 이러한 것들만으로는 IdP를 목표로 한 정교한 공격으로부터 보호하기에 충분하지 않을 수 있습니다. 공격자들은 끊임없이 기술을 발전시키고 있으며, 전통적인 보안 조치는 한계나 취약점이 있어 악용될 수 있습니다.

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

클러스터 전반에 걸쳐 WebAuthn 설정

WebAuthn 표준을 사용하여 여러분의 전체 인프라에서 강력하고 피싱 저항적인 인증을 구현하세요. WebAuthn은 W3C 표준이자 FIDO2의 일부로, 웹 인증을 위한 공개 키 암호화를 가능하게 합니다. Teleport는 SSH 노드나 Kubernetes 클러스터에 로그인할 때(Web UI를 통해) 다단계 인증으로 WebAuthn을 지원합니다. YubiKeys, SoloKeys와 같은 하드웨어 키 및 Touch ID, Windows Hello와 같은 생체 인증 방식과 호환됩니다.

전제 조건

실행 중인 Teleport 클러스터 또는 Teleport Cloud, 버전 16 이상. Teleport를 시작하려면 가입하세요 무료 체험을 원하신다면.
tctl 관리 도구와 tsh 클라이언트 도구.

설치를 방문하여 tctl와 tsh를 다운로드하는 방법에 대한 지침을 확인하세요.
YubiKey 또는 SoloKey와 같은 WebAuthn 하드웨어 장치
WebAuthn 지원이 있는 웹 브라우저
당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오.

예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다.

자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

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

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 지원을 활성화하려면 이 필드를 'on', 'optional' 또는 'webauthn'으로 설정하세요.
  second_factor: "on"
  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가 업데이트되었습니다

`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
장치 유형 선택 [TOTP, WEBAUTHN]: webauthn
장치 이름 입력: desktop yubikey
등록된 보안 키를 탭하거나 등록된 OTP 장치에서 코드를 입력하세요:
새 보안 키를 탭하세요
MFA 장치 "desktop yubikey"가 추가되었습니다.

단계 3/3. WebAuthn을 사용하여 로그인

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

tsh login --proxy=example.teleport.sh
Teleport 사용자 codingllama의 비밀번호를 입력하세요:
보안 키를 탭하거나 OTP 장치에서 코드를 입력하세요:
> 프로필 URL:        https://example.teleport.sh
로그인 된 사용자:       codingllama
클러스터:            example.teleport.sh
역할:              access, editor, reviewer
로그인:             codingllama
Kubernetes:         사용 가능
유효 기간:        2021-10-04 23:32:29 -0700 PDT [유효 기간 12h0m0s]
확장:         permit-agent-forwarding, permit-port-forwarding, permit-pty

Note

Teleport에 로그인할 때 WebAuthn은 로컬 사용자에게만 필요합니다. SSO 사용자는 SSO 제공자에서 다단계 인증을 구성해야 합니다.

세션별 MFA 구성

초기 로그인뿐만 아니라 각 세션에 대해 다단계 인증이 필요하도록 하여 지속적인 보안을 유지하세요. Teleport의 세션별 MFA는 디스크에서 손상된 인증서를 보호하여 보안을 강화합니다. 새로운 SSH, Kubernetes, 데이터베이스 또는 데스크탑 세션을 시작할 때 추가 MFA 검사를 요구합니다.

Teleport는 새로운 시작 시 추가 다단계 인증 검사를 요구하는 것을 지원합니다:

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

세션별 MFA 외에도, SSO 제공자에서 로그인 MFA를 활성화하고 모든 로컬 Teleport 사용자를 위해 보안을 강화하세요.

단계 1/2. MFA 검사를 시행하세요

모든 역할에 대해 MFA 검사를 시행하려면 클러스터 인증 구성을 편집하세요:

기존의 cluster_auth_preference 리소스를 가져오세요:

tctl get cap > cap.yaml

cap.yaml에 다음 내용이 포함되어 있는지 확인하세요:

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

tctl create -f cap.yaml

기존의 cluster_auth_preference 리소스를 가져오세요:

tctl get cap > cap.yaml

cap.yaml에 다음 내용이 포함되어 있는지 확인하세요:

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

단계 2/2. 리소스 생성

tctl create -f cap.yaml

역할별

특정 역할에 대해 MFA 검사를 시행하려면 역할을 업데이트하여 다음을 포함하세요:

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

클러스터 전반에 걸쳐 장치 신뢰 구현

조직 전반에서 신뢰할 수 있는 장치를 검증하고 관리하는 시스템을 개발하여, 알 수 없거나 손상된 장치로 인한 무단 접근의 위험을 줄이세요. 장치 신뢰는 보호된 리소스에 접근하기 위해 신뢰할 수 있는 장치의 사용을 요구하며, 사용자 아이덴티티 및 역할 강화를 보완하여 보안을 강화하는 추가 레이어를 추가합니다. 이는 클러스터 전반에 걸쳐 또는 RBAC를 통해 구성할 수 있습니다. 지원되는 리소스에는 앱(역할 기반만 가능), SSH 노드, 데이터베이스, Kubernetes 클러스터 및 첫 번째 MFA 장치 등록이 포함됩니다. 후자는 손상된 IdP를 통한 사용자의 자동 프로비전 방지를 지원합니다.

Machine ID 및 장치 신뢰

현재 Machine ID 및 장치 신뢰를 지원하지 않습니다. 클러스터 전반에 걸쳐 장치 신뢰를 요구하거나 Machine ID로 가장한 역할에 대해 요구하면 Machine ID로 생성된 자격 증명이 리소스에 연결하는 데 사용될 수 없습니다.

우회 방법으로, 역할별로 장치 신뢰 시행을 구성하고, Machine ID를 사용하여 가장할 역할에 대해 이를 요구하지 않도록 설정하세요.

전제 조건

macOS 장치를 등록하려면 다음이 필요합니다:
- 서명되고 공증된 tsh 바이너리. macOS tsh 설치 프로그램 다운로드.
Windows 장치를 등록하려면 다음이 필요합니다:
- TPM 2.0이 있는 장치.
- 관리자 권한이 있는 사용자. 이는 등록 중에만 필요합니다.
- tsh v13.1.2 이상. Windows tsh 설치 프로그램 다운로드.
Linux 장치를 등록하려면 다음이 필요합니다:
- TPM 2.0이 있는 장치.
- /dev/tpmrm0 장치를 사용할 수 있는 권한이 있는 사용자(일반적으로 tss 그룹을 사용자에게 할당하여 수행합니다).
- tsh v15.0.0 이상. Linux용 tsh 설치.
웹 UI 세션을 인증하려면 Teleport Connect가 필요합니다.

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

자체 등록: v13.3.5+

editor 또는 device-admin 역할(버전 v13.3.6부터)을 사전 설정한 사용자는 다음 명령으로 단일 단계에서 장치를 등록하고 등록할 수 있습니다:

tsh device enroll --current-device

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

장치를 등록하기 전에 먼저 장치를 등록해야 합니다. 장치를 등록하려면, 해당 장치의 시리얼 넘버를 확인해야 합니다.

장치의 시리얼 넘버를 tsh로 검색하세요 (등록하려는 장치에서 실행해야 함):

tsh device asset-tag
C00AA0AAAA0A

시리얼 번호는 Apple 메뉴 -> "이 Mac에 관하여" -> "시리얼 번호"에서 볼 수 있습니다.

Windows 및 Linux 장치는 제조업체에 의해 설정된 구성에 따라 여러 시리얼 번호를 가질 수 있습니다.

Teleport는 다음 중 첫 번째 사용 가능한 값을 선택합니다:

시스템 자산 태그
시스템 시리얼 번호
메인 보드 시리얼 번호

Teleport에서 선택한 값을 찾으려면 다음 명령을 실행하세요:

tsh device asset-tag
C00AA0AAAA0A

C00AA0AAAA0A를 등록할 장치의 시리얼 번호로 교체하고, tctl devices add 명령을 실행합니다:

tctl devices add --os='macos' --asset-tag='C00AA0AAAA0A'
장치 C00AA0AAAA0A/macOS가 인벤토리에 추가되었습니다

장치가 등록되었는지 확인하려면 tctl을 사용하세요:

tctl devices ls
자산 태그    OS    등록 상태 장치 ID------------ ----- ------------- ------------------------------------C00AA0AAAA0A macOS 등록되지 않음  9cdfc0ad-64b7-4d9c-this-is-an-example

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

등록된 장치는 등록 의식 과정을 거친 후 신뢰할 수 있는 장치가 됩니다. 장치를 등록하려면 장치 등록 토큰이 필요합니다. 이 토큰은 장치 관리자가 생성하여 등록을 수행하는 사람에게 오프밴드(예: 기업 채팅)를 통해 전송합니다.

등록할 장치의 시리얼 번호인 --asset-tag를 포함하여 명령을 실행하세요:

tctl devices enroll --asset-tag="C00AA0AAAA0A"
등록할 장치 "C00AA0AAAA0A"에서 다음 명령을 실행하세요:tsh device enroll --token=AAAAAAAAAAAAAAAAAAAAAAAA-this-is-an-example

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

등록 의식을 수행하기 위해 위에서 지정한 장치를 사용하여 tctl devices enroll에서 출력된 명령을 입력하세요:

tsh device enroll --token=AAAAAAAAAAAAAAAAAAAAAAAA-this-is-an-example
장치 "C00AA0AAAA0A"/macOS가 등록되었습니다.
tsh logout
tsh login --proxy=teleport.example.com --user=myuser # 새로운 인증서 가져오기
Teleport 사용자 myuser의 비밀번호를 입력하세요:보안 키를 탭하세요보안 키 탭 감지됨> 프로필 URL:        teleport.example.com:443  로그인 된 사용자:       myuser  클러스터:            teleport.example.com  역할:              access, editor  로그인:             myuser  Kubernetes:         사용 가능  유효 기간:        2023-06-23 02:47:05 -0300 -03 [유효 기간 12h0m0s]  확장:         teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id

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

자동 등록

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

자동 등록이 작동하기 위해서는 다음 조건이 충족되어야 합니다:

장치가 등록되어 있어야 합니다. 등록은 수동으로 수행되거나 Jamf Pro 통합과 같은 통합을 통해 수행될 수 있습니다.
클러스터 설정에서 자동 등록이 활성화되어 있어야 합니다.
사용자는 사전 설정된 editor 또는 device-enroll(버전 v13.3.6부터 이용 가능) 역할이 부여되어 있어야 합니다.

Tip

Teleport v16.1.1부터 사용자는 자동 등록의 혜택을 누리기 위해 장치/등록 권한이 필요하지 않습니다.

단계 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
모든 사용자가 로그아웃되었습니다.tsh login --proxy=teleport.example.com --user=myuser
Teleport 사용자 myuser의 비밀번호를 입력하세요:보안 키를 탭하세요보안 키 탭 감지됨> 프로필 URL:        teleport.example.com:443  로그인 된 사용자:       myuser  클러스터:            teleport.example.com  역할:              access, editor  로그인:             myuser  Kubernetes:         사용 가능  유효 기간:        2023-06-23 02:47:05 -0300 -03 [유효 기간 12h0m0s]  확장:         teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id

teleport-device-* 확장이 있는 것은 장치가 성공적으로 등록되고 인증되었음을 나타냅니다.

관리자 작업에 MFA 요구

민감한 관리 작업에 대해 다단계 인증을 요구하여 보안을 강화하세요. Teleport는 모든 클라이언트(tctl, tsh, Web UI 및 Connect)에서 관리자 작업에 대해 추가 MFA 검증을 강제합니다. 이 기능은 모든 관리 작업 전에 사용자 아이덴티티를 즉시 재확인하여 손상된 관리자 계정으로 인한 위험을 완화하는 추가 보안 레이어를 제공합니다.

이러한 고급 보안 조치를 채택하면 IdP 침해에 대한 강력한 방어를 구축하고 조직의 공격 가능성을 크게 줄일 수 있습니다. 다음 섹션에서는 이러한 권장 사항 각각에 대해 더 깊이 탐구하고 구현 및 모범 사례에 대한 단계별 가이드를 제공합니다.

관리 작업에 대해 MFA가 활성화되면, tctl auth sign으로 생성된 사용자 인증서가 추가 MFA 검사로 인해 자동화에 적합하지 않게 됩니다.

우리는 사용자가 관리 작업에 대해 MFA 검사가 필요하지 않도록 Machine ID를 사용하여 자동화 워크플로를 위한 인증서를 발급하는 것을 권장합니다.

super-admin 역할을 사용하여 Auth Service 인스턴스에서 tctl auth sign으로 직접 생성된 인증서는 레거시 자체 호스팅 설정을 지원하기 위해 MFA 검사의 적용을 받지 않습니다.

전제 조건

당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
이 클러스터에서 WebAuthn 구성됨
YubiKey 또는 SoloKey와 같은 다단계 하드웨어 장치
SSH 또는 Teleport Web UI의 데스크탑 세션을 사용하는 경우 WebAuthn 지원이 있는 웹 브라우저.

관리 작업에 대한 MFA는 WebAuthn이 유일한 다단계 형태로 허용되는 클러스터에서 자동으로 시행됩니다.

향후 주요 버전에서 Teleport는 더 광범위한 클러스터 구성에서 관리 작업에 대한 MFA를 시행할 수 있습니다.

관리 작업의 예로는 다음과 같은 것들이 포함되지만 이에 국한되지 않습니다:

사용자 계정 재설정 또는 복구
새로운 사용자 초대
클러스터 구성 리소스 업데이트
접근 관리 리소스 수정
접근 요청 승인
새로운 가입 토큰 생성
역할 가장
Machine ID를 위한 새로운 봇 생성

이것은 사용자들이 그들의 디스크 기반 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
  # webauthn을 유일한 다단계 형태로 지정하려면 이 필드를 'webauthn'으로 설정하세요.
  second_factor: "webauthn"
  webauthn:
    rp_id: example.com

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

명령 tctl이 원격 정의를 업데이트하게 됩니다:

cluster auth preference가 업데이트되었습니다

다음 단계

추가 클러스터 강화 조치를 보려면, 다음을 참조하세요:

패스워드 없는 인증: 패스워드 및 사용자 이름 없는 인증을 제공합니다.
잠금: 활성 사용자 세션 또는 호스트의 접근을 잠급니다.
조정된 세션: 세션 감사자를 요구하고 미세하게 실시간 세션 접근을 허용합니다.
하드웨어 키 지원: 하드웨어 기반 개인 키 사용을 강제합니다.

Teleport 원문 보기

클러스터 전반에 걸쳐 WebAuthn 설정

전제 조건

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

webauthn 필드 정의

단계 2/3. 사용자의 WebAuthn 장치 등록

단계 3/3. WebAuthn을 사용하여 로그인

세션별 MFA 구성

단계 1/2. MFA 검사를 시행하세요

단계 2/2. 리소스 생성

역할별

클러스터 전반에 걸쳐 장치 신뢰 구현

전제 조건

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

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

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

자동 등록

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

단계 2/2. 로그아웃하고 다시 로그인

관리자 작업에 MFA 요구

전제 조건

단계 1/2. 리소스 편집

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

다음 단계

`webauthn` 필드 정의