하드웨어 키 지원 | Teleport 공식 기술 문서 한국판 by 인포그랩

하드웨어 키 지원

기업용

하드웨어 키 지원은 Teleport Enterprise가 필요합니다.

기본적으로, tsh , Teleport Connect, 그리고 기타 Teleport 클라이언트는 사용자의 키와 인증서를 직접 파일 시스템에 저장합니다. 사용자의 파일 시스템이 손상되면, 그들의 활성 Teleport 사용자 키와 인증서도 손상될 수 있습니다.

사용자가 Teleport 서비스, 예를 들어 SSH 서비스, Kubernetes 서비스, 데이터베이스 서비스 등으로 새로운 세션을 시작할 때 다중 요소 인증 체크를 요구하도록 세션별 MFA를 구성할 수 있습니다. 그러나 세션별 MFA는 손상된 세션 자격 증명이 tctl 을 통한 관리 명령 실행과 같은 다른 작업을 방지하지는 않습니다.

이러한 유형의 공격을 방지하기 위해, Teleport는 하드웨어 기반 개인 키를 지원합니다. 디스크 기반 개인 키와 달리, 하드웨어 기반 개인 키는 하드웨어 장치에서 직접 생성되고 저장되며 내보내기가 불가능합니다. 하드웨어 기반 개인 키를 사용하면, 로그인 세션은 키가 생성되고 저장된 하드웨어 장치에 접근할 수 있는 경우에만 작동합니다.

추가로, 이 기능을 모든 Teleport 요청에 대해 터치를 요구하도록 구성할 수 있습니다. 비세션 요청인 tctl edit 와 같은 요청도 포함됩니다. 터치가 요구되는 경우, 하드웨어 키 지원은 세션별 MFA보다 더 나은 보안을 제공합니다.

터치 캐싱

사용자의 터치는 과도한 터치 프롬프트를 방지하기 위해 하드웨어 보안 키에 15초 동안 캐시됩니다.

호환성

하드웨어 키 지원은 최상의 보안을 제공합니다. 그러나 모든 서비스가 하드웨어 키와 호환되는 것은 아닙니다.

지원됨:

Teleport 클라이언트 tsh , tctl , 및 Teleport Connect.
tsh ls , tctl create 등과 같은 표준 Teleport API 요청.
서버 접근.
에이전트 없는 OpenSSH 서버 접근.
tsh db connect 대신 tsh proxy db 를 통한 데이터베이스 접근.
tsh kube login 대신 tsh proxy kube 를 통한 Kubernetes 접근.
웹 접근 (Teleport 웹 UI).
애플리케이션 접근.

지원되지 않음:

데스크탑 접근.
이전 OpenSSH 서버 접근.

사용자가 인프라에 접근하기 위해 하드웨어 키를 요구하는 경우, 그들은 지원되지 않는 기능을 사용할 수 없으며, 이는 하드웨어 키에 접근할 수 없거나 프로토콜이 원시 개인 키만 지원하기 때문입니다.

이러한 비호환성을 극복하기 위해, 우리는 하드웨어 키 지원을 필요한 경우에만 활성화하는 것을 추천합니다. 예를 들어, 중요 인프라에 대한 접근 권한이 있는 역할들에 대해 활성화할 수 있습니다. 이러한 역할은 접근 요청을 통해 필요할 때 접근할 수 있으며 사용자가 일반 로그인 세션에서 이러한 문제를 피할 수 있습니다.

참고: 웹 및 앱 세션은 하드웨어 키에 의해 직접 지원되지 않지만, 인증 서비스 및 프록시 서비스에 의해 엄격히 보호됩니다. 따라서 웹 및 앱 세션은 하드웨어 키 지원을 우회할 수 있는 권한이 부여되며, 사용자의 존재 또는 검증이 필요할 때 추가 MFA 프롬프트로 돌아갑니다, 예를 들어 세션별 MFA와 같은 경우입니다.

필수 조건

실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.
tctl 관리자 도구 및 tsh 클라이언트 도구.

tctl 및 tsh 다운로드에 대한 지침은 설치 를 방문하십시오.

시리즈 5+ YubiKey

PIV 지원

하드웨어 키 지원은 사용자가 PIV 호환 하드웨어 키를 사용해야 합니다. 현재 이 기능은 YubiKey 시리즈 5+에 대해서만 보장됩니다.

운영 체제에 맞는 스마트 카드 드라이버를 설치합니다. Teleport 클라이언트는 스마트 카드 드라이버를 통해 YubiKey에 연결하여 키를 생성하고 암호화 작업을 수행합니다.
- macOS와 Windows는 모두 스마트 카드 드라이버를 포함합니다.
  - Windows에서 문제가 발생하면, 공식 YubiKey 스마트 카드 미니 드라이버를 시도해 보십시오.
- 리눅스 배포판에서는 YubiKey 관리자 또는 Yubico PIV 도구를 다운로드하여, 이 둘은 리눅스 스마트 카드 드라이버를 종속성으로 포함하고 있습니다.
연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/2단계. 하드웨어 키 지원 강제 적용

하드웨어 키 지원은 기본적으로 필요하지 않습니다.

하드웨어 키 지원을 위한 세 가지 주요 옵션이 있습니다:

hardware_key : 사용자 키가 터치/PIN 보호 없이 하드웨어 키에 저장됩니다. 세션 및 중재 세션과 같은 다른 MFA 의존 기능을 위한 별도의 MFA 검사가 사용됩니다.
hardware_key_touch : 사용자 키가 터치 보호와 함께 하드웨어 키에 저장됩니다. 각 요청 시, 사용자는 하드웨어 키를 터치해야 합니다.
hardware_key_touch_and_pin : 사용자 키가 터치 및 PIN 보호와 함께 하드웨어 키에 저장됩니다. 각 요청 시, 사용자는 하드웨어 키를 터치하고 PIV PIN을 입력해야 합니다.
- PIV 코드를 설정하지 않은 사용자는 로그인 중에 설정하라는 메시지가 표시됩니다.

특정 역할에 대해 하드웨어 키 지원을 강제 적용할 수 있으며, 아래와 같이 설정할 수 있습니다:

kind: role
metadata:
  name: admin
spec:
  options:
    require_session_mfa: hardware_key_touch

Teleport 구성을 업데이트하여 클러스터 전체에 하드웨어 키 지원을 강제 적용할 수도 있습니다:

tctl edit cap

spec.require_session_mfa 의 값을 hardware_key_touch 로 설정합니다:

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

편집기를 저장하고 종료한 후, tctl 이 리소스를 업데이트합니다:

클러스터 인증 기본 설정이 업데이트되었습니다

2/2단계. 로그인

역할 또는 클러스터를 하드웨어 키를 요구하도록 구성하면, 해당 역할로 로그인하거나 해당 클러스터에 로그인하는 모든 사용자는 모든 Teleport 요청에 대해 하드웨어 키를 사용해야 합니다.

영향을 받는 사용자는 로그인하기 위해 YubiKey를 연결하고 터치하라는 메시지가 표시됩니다. 사용자가 하드웨어 키로 처음 로그인하면 즉시 다시 로그인해야 할 수도 있습니다.

tsh login --user=dev --proxy=proxy.example.com:3080
Teleport 사용자 dev의 비밀번호를 입력하십시오:
충족되지 않은 개인 키 정책 "hardware_key_touch".
하드웨어 기반 개인 키로 다시 로그인하는 중입니다.
Teleport 사용자 dev의 비밀번호를 입력하십시오:
YubiKey를 탭하세요
> 프로필 URL:        https://example.com
로그인된 사용자:    dev
클러스터:          example.com
...

tsh login --user=dev --proxy=proxy.example.com:3080
Teleport 사용자 dev의 비밀번호를 입력하십시오:
충족되지 않은 개인 키 정책 "hardware_key_touch".
하드웨어 기반 개인 키로 다시 로그인하는 중입니다.
Teleport 사용자 dev의 비밀번호를 입력하십시오:
YubiKey를 탭하세요
> 프로필 URL:        https://example.com
로그인된 사용자:    dev
클러스터:          example.com
...

tsh login --user=dev --proxy=proxy.example.com:3080
Teleport 사용자 dev의 비밀번호를 입력하십시오:
충족되지 않은 개인 키 정책 "hardware_key_touch".
하드웨어 기반 개인 키로 다시 로그인하는 중입니다.
Teleport 사용자 dev의 비밀번호를 입력하십시오:
YubiKey를 탭하세요
> 프로필 URL:        https://example.com
로그인된 사용자:    dev
클러스터:          example.com
...

하드웨어 키로 백업되지 않은 기존 세션이 있는 영향을 받는 사용자는 다음 요청 시에 다시 로그인하라는 메시지가 표시됩니다. 예를 들어:

tsh clusters
충족되지 않은 개인 키 정책 "hardware_key_touch"
하드웨어 기반 개인 키로 다시 로그인하는 중입니다.
Teleport 사용자 dev의 비밀번호를 입력하십시오:
YubiKey를 탭하세요
클러스터 이름 상태 클러스터 유형 레이블 선택됨
----------- ------ ------------ ------ --------
example.com 온라인 루트                *

사용자 지정 PIV 설정

사용자 지정 PIV 슬롯

기본적으로, Teleport 클라이언트는 각 옵션에 대해 다음 PIV 슬롯을 사용합니다:

hardware_key : 슬롯 9a
hardware_key_touch : 슬롯 9c
hardware_key_touch_and_pin : 슬롯 9d
hardware_key_pin : 슬롯 9e

다른 PIV 애플리케이션을 사용하는 경우, 다른 슬롯을 지정해야 할 수 있습니다.
예를 들어, yubikey-agent 는 슬롯 9a 를 사용합니다. yubikey-agent 키와 인증서를 덮어쓰지 않으려면,
hardware_key 요구 사항이 있는 사용자는 다른 슬롯을 지정해야 합니다.

로그인 중에 사용자는 --piv-slot 명령 줄 옵션 또는 환경 변수를 사용하여 PIV 슬롯을 지정할 수 있습니다.
예를 들어:

tsh login --piv-slot=9c
TELEPORT_PIV_SLOT=9c tsh login

PIV 슬롯은 구성 옵션을 통해 클러스터 전역으로 설정할 수도 있습니다:

kind: cluster_auth_preference
metadata:
  ...
  name: cluster-auth-preference
spec:
  ...
  require_session_mfa: hardware_key
  hardware_key:
    piv_slot: 9c
  ...
version: v2

사용자 지정 키

Teleport 클라이언트는 기본 관리 키를 사용하여 지정된 슬롯에서 키를 생성합니다.

PIV 키가 다른 관리 키를 사용하는 경우, 직접 키를 생성해야 합니다.
이는 YubiKey Manager CLI를 통해 수행할 수 있습니다:

ykman piv keys generate -a ECCP256 [slot] --touch-policy=[never|cached|always] --pin-policy=[never|once|always] -

이 명령을 실행한 후에, 요청을 완료하기 위해 관리 키를 입력하라는 메시지가 표시됩니다.
클러스터와 역할에 대한 하드웨어 키 요구 사항을 충족하는 터치 및 PIN 정책을 설정하세요.

문제 해결

`ERROR: private key policy not met`

사용자가 요구되는 개인 키 정책을 충족하지 못한 경우, Auth 및 Proxy 서비스는 이 오류를 반환합니다.
tsh 및 Teleport Connect는 이러한 오류를 자동으로 감지하며, 사용자가 유효한 하드웨어 기반 개인 키로 다시 로그인하도록 요구합니다.

`ERROR: authenticating with management key: auth challenge: smart card error 6982: security status not satisfied`

잘못된 관리 키가 사용될 경우 스마트 카드 인증 챌린지 오류가 발생할 수 있습니다.

Teleport 클라이언트는 기본 관리 키가 있는 새 PIV 키를 예상합니다.
YubiKey Manager CLI의 ykman piv reset 을 사용하여 이 키를 재설정할 수 있습니다.

다른 관리 키를 사용하려면, 사용자 지정 PIV 설정 지침을 따르십시오.

`ERROR: ssh: handshake failed: command failed: transmitting request: an attempt was made to end a non-existent transaction`

가끔, Yubikey와의 PIV 상호작용이 예기치 않게 실패할 수 있습니다.

예를 들어, MFA를 위해 Yubikey를 터치한 후, 하드웨어 키 지원을 위해 Yubikey를 터치하면
드물게 오류가 발생할 수 있습니다.

왜 로그인하려고 여러 번 터치를 하라는 요청을 받나요?

설정에 따라 여러 번 Yubikey를 터치하라는 요청을 받을 수 있습니다.
각 터치는 안전하게 인증하기 위해 필요합니다.

예를 들어, cluster_auth_preference 에 second_factor: webauthn 이 설정되어 있고,
역할에 require_session_mfa: hardware_key_touch 가 설정된 경우,
처음 로그인할 때 다음과 같은 출력이 표시됩니다:

tsh login --user=dev --proxy=root.example.com:3080

인증되지 않은 클라이언트는 사용자의 역할에 의해 요구되는
"hardware_key_touch"를 추론할 수 없기 때문에 일반적으로 처음 로그인합니다.

Enter password for Teleport user dev:Tap any security keyDetected security key tap
로그인의 결과는 "hardware_key_touch" 오류입니다.

충족되지 않은 개인 키 정책 "hardware_key_touch".
이 시점에서, `tsh` 는 오류로부터 사용자의 역할이
"hardware_key_touch"를 요구한다는 것을 추론할 수 있으며,
하드웨어 키에서 직접 개인 키를 생성하고 로그인 프로세스를 다시 시작합니다.

하드웨어 지원 개인 키로 다시 로그인 중입니다.
이번에는, `tsh` 가 로그인 요청에서 Yubikey 지원 개인 키를 사용하여
사용자의 역할에 대한 개인 키 정책을 통과하는 인증서를 가져옵니다.

Enter password for Teleport user dev:Tap any security keyDetected security key tapTap your YubiKey> Profile URL:        https://root.example.com:3080  Logged in as:       dev  Cluster:            root.example.com  ...

Teleport 원문 보기