Vault 사용
이전에도 KMS의 사용법을 소개한 적이 있고, 그 장점과 용도에 대해 언급한 적이 있습니다. 우리가 사용하는 시나리오는 다음과 같습니다.
AWS를 떠난다면 선택은 정말 아닌 것 같습니다. 너무 많습니다. Harshicorp의 Vault는 제가 아는 유일한 제품이며 RatticDB는 그 중 절반을 차지합니다.
Vault는 안전한 저장(키/값)과 토큰, 비밀번호, 인증서, API 키 등에 대한 제어 기능을 제공합니다. 키 갱신, 해지, 감사 및 기타 기능을 처리할 수 있습니다. API 접속을 통해 암호화되어 저장된 비밀번호, SSH 키, X.509 인증서 등을 얻을 수 있습니다. 그 기능은 다음과 같습니다:
Vault를 사용하는 목적은
Vault 저장 [백엔드( 포즈 파일은 다음과 같습니다:
볼륨 생성, Vault 서버 시작 , 구성 환경 변수 VAULT_LOCAL_CONFIG를 통해 전달하세요.
로컬 포트 8200에서 액세스할 수 있어야 합니다.
다음 API 요청은 Vault를 초기화할 수 있습니다. 마스터 키를 여러 부분으로 나누어 복원하고, 여기에서 1개를 사용하세요.
반환 결과:
첫 번째는 마스터 키의 공개 키이고 두 번째는 개봉 키입니다. , 마지막은 루트 토큰입니다. 볼트 해제 후에만 특정 작업을 확인할 수 있습니다.
결과:
보안상의 이유로 루트 토큰을 사용할 수 있습니다. 다음 작업을 계속하기 위한 제한된 권한이 있는 새 토큰. 이 토큰이 읽고 쓸 수 있는 경로가 secret/*라고 가정합니다. 그 전에 먼저 이 경로에 액세스하기 위한 정책을 만듭니다. 해당 사용자 정책을 만듭니다:
관리자 토큰과 사용자 토큰이라는 두 개의 토큰을 만듭니다.
이 방법으로 secrets/* 경로 아래에 읽고 쓰기 위한 두 개의 토큰이 있습니다. . 관리자 토큰에 새 키-값 쌍을 추가할 수 있습니다.
이는 볼트 서버와 애플리케이션 서버 또는 CI 서버가 동일한 개인 네트워크에 배포되어 있다고 가정할 때 제공됩니다. 애플리케이션 서버와 CI 슬레이브는 ssh를 할 수 없기 때문에 애플리케이션 서버나 CI를 통해 시작 시 HTTP 요청과 읽기 권한이 있는 사용자 토큰을 통해 API-TOKEN을 얻을 수 있으며 외부에 노출되지 않습니다.
AWS EC2 인스턴스는 IAM 역할에 해당하는 instanceProfile에 바인딩될 수 있으며, 이 역할은 특정 S3 버킷에 대한 쓰기 권한 또는 Dynamodb에 대한 쓰기 권한 등과 같은 AWS 리소스에 대한 액세스 권한을 설정할 수 있습니다. Vault에서 제공하는 AppRoles의 성능은 instanceProfile보다 훨씬 나쁩니다. 하지만 실제로는 특정 권한이 있는 역할에 바인딩하여 액세스 범위를 제어할 수 있습니다.
승인 확인 방법을 사용하고 동시에 CI 슬레이브에 대한 역할을 생성할 수 있습니다.
다음 API 요청은 역할 ID를 가져오고 기반 비밀 ID를 생성할 수 있습니다. role-id에서 이를 사용하여 로그인하고 저장소에서 데이터를 읽을 수 있는 권한을 얻을 수 있습니다.
secret_id 및 role_id를 사용하여 공동으로 로그인하고 새 토큰을 얻습니다.
그런 다음 client_token을 사용하여 이전 쓰기를 읽습니다. 볼트의 검색 API 토큰으로 이동합니다.
AWS EC2 인스턴스 서버를 시작할 때 SSH 키 쌍 쌍을 바인딩하여 사용자가 기본 키 쌍을 쉽게 사용할 수 있습니다. ec2-user ssh를 서버에 연결합니다. 모범 사례 관점에서 서버는 SSH가 허용되지 않는 불변 시설로 취급되어야 합니다. 그러나 현실은 더욱 냉소적입니다. 이러한 요구는 여전히 존재하므로 SSH 키를 관리하는 데 최선을 다할 수 있습니다.
예를 들어, 새로 시작된 각 서버에 대해 SSH 키 쌍 쌍이 동적으로 생성되어 이 서버에만 적용되며, 서버가 파괴된 후에는 키 쌍이 취소됩니다.
Vault는 SSH 키 쌍 관리 기능을 제공하며, 이 기능을 사용하여 키의 수명주기를 관리할 수 있습니다. 두 가지 방법을 지원합니다:
Vault에서 키 쌍을 발급하려면 먼저 서버에 대한 관리 권한이 있어야 하는 개인 키를 등록해야 합니다. 그런 다음 일부 역할을 포함하여 역할을 만들어야 합니다. admin 등의 자격 사용자 이름, 기본 사용자, 대상 서버의 IP 주소가 일치해야 하는 CIDR 주소입니다. 구체적인 프로세스는 다음과 같습니다.
전체 프로세스는 Vault에서 사용됩니다. 등록된 개인키를 사용하여 대상 서버에 로그인한 후 새로 생성된 키 쌍의 공개 키를 대상 서버의 Authorized_keys 파일에 씁니다. 서버에 로그인하려면 해당 클라이언트 토큰을 사용하여 검증하고 개인 키를 얻은 후 SSH를 통해 로그인하십시오. 키에는 만료 시간이 있으며 만료 후에는 취소됩니다.
웹사이트 전체 https의 어려움 중 하나는 PKI 관리에 있다고 생각합니다. 올해는 인증서 만료로 인해 여러 가지 제품 환경 문제가 발생하여 다행히 AWS Certificate Manager로 전환했습니다. , 무료이며 자동으로 만료됩니다. 임대를 갱신하면 기본적으로 관리 문제에 대해 걱정할 필요가 없습니다. 원래 내부 PKI 관리는 좀 더 까다롭습니다. 자체 비즈니스 라인의 LOB 중간 CA를 사용하여 새 인증서를 발급하고 일부 자동화된 스크립트를 실행하고 RatticDB에서 해당 개인 키를 찾아야 합니다.
하지만 인프라가 AWS 기반이 아닌 경우 적합한 도구가 없는 것 같고, PKI를 직접 유지 관리할 수 밖에 없습니다. Vault도 이와 관련하여 도움이 될 수 있는 PKI 관리를 제공합니다. 환경의 일관성을 고려하면 개발, 테스트, 스테이징에도 인증서가 필요하다고 생각합니다.
Vault는 루트 CA의 개인 키를 안전하게 저장합니다. http 요청을 통해 ca의 pem 파일을 얻을 수 있습니다.
CA 및 CRL(인증서 해지 목록)에 액세스하려면 Vault를 주소로 구성해야 합니다.
중간 CA를 생성합니다.
example_lob.csr 파일에 csr 콘텐츠를 저장하고 루트 CA에 중간 CA에 서명하도록 요청합니다.
루트 CA에서 발급한 중간 CA 인증서를 획득한 후 파일로 저장하고 가져옵니다. 마지막 단계는 위와 동일하게 CA/CRL을 설정하는 것입니다.
서버에 인증서 발급을 시작하기 전에 역할을 생성한 후 발급하면 됩니다.
개인 키와 crt를 얻으면 테스트를 위해 서버에 넣을 수 있습니다. 이 grunt-connect-proxy를 사용하면 테스트가 더 빨라질 수 있다고 생각합니다.
제가 생각하는 Vault의 또 다른 기능은 인증의 백엔드로 LDAP를 사용할 수 있다는 것입니다. 유지 관리 부담이 훨씬 덜하다고 생각합니다. :) 나머지 기능은 직접 사용해 볼 수 있으며, 저희는 개인 키와 같은 일부 자격 증명을 저장하기 위해 RatticDB를 교체하는 것도 고려하고 있습니다. 다음 보안 회의에서 스파이크 결과를 보여줄 수 있습니다.