서명 알고리즘
Teleport Auth Service는 모든 연결을 인증, 권한 부여 및 암호화할 수 있도록 사용자와 호스트에게 SSH 및 TLS 인증서를 발급합니다. 계속 읽으면 다음을 수행하는 방법을 알 수 있습니다: Teleport 17 이후에 생성된 새 Teleport 클러스터는 대부분의 경우 타원 곡선 키를 자동으로 사용합니다.
Teleport Auth Service는 모든 연결을 인증, 권한 부여 및 암호화할 수 있도록 사용자와 호스트에게 SSH 및 TLS 인증서를 발급합니다. 이 페이지에서는 Teleport가 발급하는 각 종류의 인증서에 서명하는 데 사용되는 암호화 서명 알고리즘을 설명합니다.
계속 읽으면 다음을 수행하는 방법을 알 수 있습니다:
- Teleport 17 이전에 생성된 Teleport 클러스터가 빠르고 안전한 타원 곡선 키를 사용하도록 구성
- FIPS 호환 서명 알고리즘을 사용하도록 클러스터 구성
- HSM 또는 KMS와 호환되는 서명 알고리즘을 사용하도록 클러스터 구성
서명 알고리즘 스위트#
Teleport 17 이후에 생성된 새 Teleport 클러스터는 대부분의 경우 타원 곡선 키를 자동으로 사용합니다. 이전 버전의 Teleport에서 클러스터를 생성한 경우, 서명 알고리즘 스위트를 구성하여 새 알고리즘을 선택할 때까지 RSA 키를 계속 사용합니다. 단일 알고리즘 스위트를 선택하면 클러스터 전반에 걸쳐 사용되는 모든 암호화 서명 알고리즘을 제어할 수 있습니다.
legacy#
legacy 스위트는 모든 서명이 2048비트 RSA 키를 기반으로 하는 원래 Teleport 동작을 식별합니다.
17.0.0 이전 버전에서 생성된 Teleport 클러스터는 사실상 항상 legacy 스위트를 사용해 왔으며, 새 버전으로 업그레이드해도 자동으로 변경되지 않습니다.
가능하다면 사용자들이 최신 스위트 중 하나로 업그레이드하는 것을 권장합니다.
balanced-v1#
balanced-v1 스위트는 버전 17.0.0 이후 생성된 셀프 호스팅 클러스터의 기본 스위트입니다.
대부분의 셀프 호스팅 사용자에게 권장하는 스위트입니다.
이 스위트를 구성하면 모든 SSH 인증서에 Ed25519가 사용되고, 모든 TLS 인증서에 NIST P-256 곡선을 사용하는 ECDSA가 사용됩니다.
RSA는 Teleport가 통합하는 일반적인 서드파티 소프트웨어가 비RSA 알고리즘을 지원할 수 없는 것으로 알려진 경우에 계속 사용됩니다.
여기에는 db 또는 db_client CA에서 발급하는 인증서와 Teleport가 발급하는 특정 JSON Web Token(JWT)이 포함됩니다.
fips-v1#
FIPS 모드로 Teleport를 배포하는 사용자는 fips-v1 스위트를 사용하는 것이 좋습니다.
FIPS 모드에서 버전 17.0.0 이후 생성된 새 클러스터는 기본적으로 이 스위트를 사용합니다.
FIPS 186-5는 비교적 최근(2023년 2월)에야 Ed25519에 대한 승인을 추가했으며, 알고리즘 사용 방법에 대한 미묘한 차이가 있습니다.
Teleport에 더 중요한 것은, FIPS Go 바이너리가 컴파일되는 boringcrypto 모듈이 아직 Ed25519를 지원하지 않는다는 점입니다.
이러한 이유로, fips-v1 스위트는 balanced-v1 스위트를 기반으로 하되, Ed25519의 모든 사용을 ECDSA로 대체합니다.
HSM 또는 KMS가 구성된 상태에서 fips-v1 스위트를 사용하는 것은 완전히 지원됩니다.
hsm-v1#
hsm-v1 스위트는 HSM 또는 KMS에 인증 기관 키 자료를 보관하기로 선택한 클라우드 고객과 셀프 호스팅 사용자를 위해 설계되었습니다.
HSM 또는 KMS가 구성된 버전 17.0.0 이후 생성된 새 클러스터의 기본 스위트입니다.
버전 17.x+에서 새 Teleport Cloud 클러스터의 기본 스위트가 될 예정입니다.
Teleport의 PKCS#11 HSM 및 클라우드 KMS와의 통합은 아직 Ed25519를 지원하지 않습니다.
이러한 이유로, hsm-v1 스위트는 balanced-v1 스위트를 기반으로 하되, 모든 인증 기관 키에서 Ed25519 대신 ECDSA를 사용합니다.
사용자 및 호스트 SSH 키는 여전히 Ed25519를 사용합니다.
FIPS 모드로 Teleport를 배포하는 경우 hsm-v1 스위트는 호환되지 않으므로, 대신 fips-v1 스위트를 사용해야 합니다.
두 스위트의 주요 차이점은 hsm-v1 스위트는 사용자 및 호스트 SSH 키에 여전히 Ed25519를 사용하는 반면, fips-v1 스위트는 Ed25519를 전혀 사용하지 않는다는 것입니다.
구성#
클러스터 서명 알고리즘 스위트는 Auth Service 구성 파일에서 정적으로 구성하거나 cluster_auth_preference 리소스에서 동적으로 구성할 수 있습니다.
정적 구성#
기본적으로 /etc/teleport.yaml에 저장된 Teleport Auth Service 구성 파일에 다음을 추가합니다.
auth_service:
authentication:
signature_algorithm_suite: "balanced-v1"
동적 리소스#
cluster_auth_preference 리소스를 편집합니다:
$ tctl edit cap
리소스에 다음 내용이 포함되어 있는지 확인합니다:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
signature_algorithm_suite: "balanced-v1"
version: v2
인증 기관#
tctl status 명령은 각 키 쌍에 사용된 알고리즘을 포함하여 Teleport 클러스터의 각 인증 기관 상태를 표시합니다.
$ tctl status
Cluster: example.teleport.sh
Version: 17.0.0
CA pins: sha256:b1419d94442b2b1ba70f967157bf177c7605020c59ee93a10b0e4d3fc526e7df
authority rotation protocol status algorithm storage
--------- ----------------------- -------- ------ ----------- --------
host standby (never rotated) SSH active Ed25519 software
TLS active ECDSA P-256 software
user standby (never rotated) SSH active Ed25519 software
TLS active ECDSA P-256 software
db standby (never rotated) TLS active RSA 2048 software
db_client standby (never rotated) TLS active RSA 2048 software
openssh standby (never rotated) SSH active Ed25519 software
jwt standby (never rotated) JWT active ECDSA P-256 software
saml_idp standby (never rotated) TLS active RSA 2048 software
oidc_idp standby (never rotated) JWT active RSA 2048 software
spiffe standby (never rotated) JWT active RSA 2048 software
TLS active ECDSA P-256 software
okta standby (never rotated) JWT active ECDSA P-256 software
각 인증 기관은 새 Teleport 클러스터를 생성할 때 Auth Service가 처음 시작될 때 자동으로 생성됩니다. 클러스터가 이미 생성된 후에 클러스터의 서명 알고리즘 스위트를 변경하면 새로운 사용자 및 호스트 키는 새 알고리즘을 사용하지만, 각 인증 기관의 키 자료는 자동으로 업데이트되지 않습니다.
기존 인증 기관에 새 서명 알고리즘을 사용하려면 각 기관에 대해 CA 교체를 완료해야 합니다. 이 경우 클러스터의 신뢰 관계를 업데이트하기 위한 수동 단계가 필요할 수 있습니다. 절차는 CA 교체 가이드에 문서화되어 있습니다. 이 프로세스는 선택적이며, CA 교체를 완료하지 않아도 클러스터는 기존 인증 기관 키로 계속 작동합니다.
알고리즘#
다음 표는 각 스위트에서 Teleport가 생성하는 각 키에 사용된 키 알고리즘을 나열합니다.
| 키 용도 | legacy |
balanced-v1 |
fips-v1 |
hsm-v1 |
|---|---|---|---|---|
| User CA (SSH) | RSA 2048 | Ed25519 | ECDSA P-256 | ECDSA P-256 |
| User CA (TLS) | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| Host CA (SSH) | RSA 2048 | Ed25519 | ECDSA P-256 | ECDSA P-256 |
| Host CA (TLS) | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| Database CA | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| Database Client CA | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| OpenSSH CA | RSA 2048 | Ed25519 | ECDSA P-256 | ECDSA P-256 |
| JWT CA | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| OIDC IdP CA | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| SAML IdP CA | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| SPIFFE CA (TLS) | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| SPIFFE CA (JWT) | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| Okta CA | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| User SSH | RSA 2048 | Ed25519 | ECDSA P-256 | Ed25519 |
| User TLS | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| Database Client | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| Database Server | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
| Host SSH | RSA 2048 | Ed25519 | ECDSA P-256 | Ed25519 |
| Host Identity | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| MachineID Identity | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| Workload ID SVID | RSA 2048 | ECDSA P-256 | ECDSA P-256 | ECDSA P-256 |
| EC2 Instance Connect | Ed25519 | Ed25519 | ECDSA P-256 | Ed25519 |
| Windows Desktop Client | RSA 2048 | RSA 2048 | RSA 2048 | RSA 2048 |
FAQ#
내 사용 사례가 새 알고리즘을 지원하지 않으면 어떻게 하나요?#
시도해보고 알려주세요!
선택한 서명 알고리즘 스위트와 함께 보안, 성능 및 호환성의 균형을 맞추는 것을 목표로 합니다.
가까운 미래에 legacy 스위트를 계속 사용해도 괜찮으며, 일부 사용자 환경에서는 필요할 수 있다고 예상합니다.
이 알고리즘들을 어떻게 선택했나요?#
Ed25519는 새 SSH 키의 사실상 표준이 된 작은 키를 가진 현대적이고 빠르며 안전한 알고리즘입니다. Teleport가 상호 작용해야 하는 모든 것과 호환되는 경우에 선호하는 방식입니다.
NIST P-256 곡선을 사용하는 ECDSA는 TLS에서 널리 사용되고 지원되며, Ed25519에 대한 충분한 지원이 없는 경우에 사용합니다. Ed25519와 유사한 속도 및 보안 속성을 가지고 있습니다.
Ed25519 또는 ECDSA를 지원하지 않는 서드파티 소프트웨어와 상호 작용하는 경우에만 RSA를 계속 사용합니다.
특정 Teleport 인증서에 대한 특정 알고리즘을 선택할 수 없는 이유는 무엇인가요?#
서명 알고리즘 스위트는 구성 부담을 단순화하도록 설계되었습니다. Teleport가 수행하는 모든 단일 서명을 수정하기 위해 100개의 구성 노브를 노출하고 싶지 않았으며, 이는 지원해야 하는 수천 가지 가능한 조합으로 이어지고 안전하지 않은 조합의 가능성을 만들 수 있습니다.
HSM이 ECDSA 키를 지원하지 않으면 어떻게 하나요?#
ECDSA 키를 지원하지 않는 PKCS#11 HSM을 사용하는 경우, legacy 알고리즘 스위트를 계속 사용하는 것을 권장합니다.
사용자와 호스트가 Ed25519 및/또는 ECDSA 키를 사용해야 하는 강한 필요가 있다면 hsm-v1 스위트로 전환할 수 있지만, 새 CA 키가 생성될 때마다 CA가 비RSA 키를 사용하는 경우 실패할 수 있습니다.
이로 인해 Auth Service가 키를 생성하려고 시도한 후 오류와 함께 종료될 수 있습니다.
새 CA 키는 새 Auth Service가 처음 시작될 때, CA 교체가 시작될 때, 또는 새 버전에 새 CA가 추가된 경우 버전 업그레이드 중에 생성될 수 있습니다.
이러한 이유로 legacy 알고리즘 스위트를 계속 사용하는 것을 권장합니다.
YubiHSM2 인증 키에 ECDSA 키에 대한 기능이 없으면 어떻게 하나요?#
YubiHSM2 가이드는 Teleport Auth Service가 YubiHSM2로 인증하는 데 사용할 인증 키를 만들 것을 권장합니다. 해당 가이드 원본 버전의 예제는 ECDSA 키로 생성하고 서명하는 데 필요한 기능 없이 인증 키를 생성했습니다. v17로 업그레이드하거나 알고리즘 스위트를 전환하기 전에, 필요한 기능을 갖춘 새 인증 키를 만들고 새 키를 사용하도록 Auth Service 구성을 업데이트하는 것을 권장합니다. 새 인증 키는 기존 CA 키를 계속 사용할 수 있습니다.
yubihsm-shell로 새 인증 키를 만들려면:
$ yubihsm-shell
Using default connector URL: http://localhost:12345
yubihsm> connect
Session keepalive set up to run every 15 seconds
# Open a session with an admin authentication key that has capabilities to create
# new authentication keys. The factory default authentication key has id:1 and
# password:password. Use the appropriate ID and password if you have changed
# these parameters.
yubihsm> session open 1
Enter password:
Created session 0
# Create a new authentication key for Teleport.
yubihsm> put authkey 0 0 "New Teleport Auth Key" 1 generate-asymmetric-key:sign-pkcs:sign-pss:sign-ecdsa:delete-asymmetric-key sign-pkcs:sign-pss:decrypt-pkcs:decrypt-oaep:sign-ecdsa
Enter password:
Stored Authentication key 0x1a92
# Make sure you can open a session with the new authentication key and password
yubihsm> session open 0x1a92
Enter password:
Created session 1
auth_service.ca_key_params.pkcs11.pin 또는 auth_service.ca_key_params.pkcs11.pin_path에서 참조하는 파일을 새 인증 키의 ID를 사용하도록 업데이트한 다음 Auth Service를 재시작합니다.
HSM과 FIPS 모드를 함께 사용하면 어떻게 하나요?#
FIPS 모드에서 Teleport를 사용하고 CA 키 저장소에 HSM 또는 KMS를 사용하는 경우, 지원되는 서명 알고리즘 스위트는 fips-v1과 legacy입니다.
fips-v1 스위트를 사용하는 것을 권장합니다.