90 일마다 SSH 키를 만료하는 시스템을 갖추십시오 90 일마다

GDPR에 대한 해석으로 90 일마다 모든 비밀번호를 변경해야하는 고객이 있습니다. 이러한 규칙을 구현할 수 있기 때문에 개발 한 웹 기반 시스템에 적합합니다. 그러나 서버에 액세스하는 데 사용되는 SSH 키의 비밀번호를 변경해야합니다.

  1. 기존 SSH 키의 비밀번호를 변경할 수 있습니까?

  2. 그렇지 않은 경우이를 처리하는 데 사용할 수있는 도구가 있습니까? 생각 중이 야:

    에이. 새 키를 작성하십시오.
    비. 모든 공개 키를 기존 서버에 배포하십시오.
    기음. 기존 공개 키를 제거하십시오.
    디. 오래된 개인 키를 보관합니다.

    여기 Puppet에 대한 게시물을 읽었지만 이해하기 때문에 공개 키를 서버에 배포하고 n 번째 날마다 새 키를 만들지 않는 문제 만 해결하려고합니까? Puppet에 대한 연구를 계속 진행해야합니까?

  3. 비밀번호 보존 및 ssh 키와 관련하여 커뮤니티 표준은 무엇입니까? 어떻게합니까?

답변

고객이 여기에 틀 렸으며 고객이 말하는 것을 이해하지 못합니다. 개인 키의 암호를 변경하는 것은 매우 직관적이지 않은 보안 속성을 가지고 있기 때문에 매우 나쁜 생각입니다.

일반적으로 사용자는 자신이 변경 한 암호를 “더 이상 비밀이 아닌”것으로 생각합니다. 가치가 낮은 사이트, 온라인 핸들 / 닉네임, 농담에 대한 펀치 라인 등의 일회용 비밀번호가 될 수 있으며, 작성된 용지는 노출 된 스크랩이 될 수 있습니다.

개인 키를 암호화하는 데 사용되는 암호 는 작동 방식이 아닙니다 ! 암호는 비밀로 유지해야 영원히 키와 관련된 모든 권한이 취소되지 않는 한 (그리고 다음은 SSH 키에 적용되지 않지만, 암호는 서명을 위해, 그러나, 개인 메시지를 수신뿐만 아니라 사용되는 키의 경우 영원히 정말 영원히 의미합니다 ). 이는 암호화 된 개인 키 파일이 공격자에 의해 얻어 졌거나 나중에 공격자가 얻을 수있는 백업과 같은 곳에 저장되었을 가능성이 있기 때문입니다. 암호가 공개되면 타협됩니다.

어떤 의미에서, 과거 암호 문구 중 하나에 대한 지식 만 있으면 공격자가 암호화 된 개인 키 파일에 액세스 할 수 있으면 키를 손상시키기에 평생 동안 N 암호를 통과 한 개인 키는 1 / N 안전 합니다. .

이제 문제로 돌아가겠습니다.

고객이이 “ssh passwords”오해에 사로 잡히지 않고 파헤친 경우, 올바른 조치를 취하지 말고 키 처리를위한 모범 사례를 따르십시오. 그러나 이제는 그들이 만족할 수 있도록 무언가를해야 할 것입니다. 개인 키를 암호화하는 암호가 암호와 다른 보안 속성을 갖는 방법을 설명해 볼 수는 있지만 고객이 여기에서 많은 일에 대해 얼마나 잘못했는지 (암호 만료는 일반적으로 나쁜 생각입니다) 나는 그것이 효과가 있을지 의심합니다.

새 키를 배포하기 위해 시스템을 자동화하는 작업이 남아 있습니다. 나는 것 강력하게 억제 하기 때문에, 중앙에 새 키를 생성하는 시스템을 자동화에서 당신을 개인 키가 기계 사이에서 이동해서는 안됩니다 . 대신 새로운 개인 키를 생성하고 해당 공개 키를 게시하고 공개 키 배포 시스템 (Puppet 또는 기타)을 보유한 액세스 권한이 필요한 직원 / 계약 업체가 쉽게 프로세스 / 알림 / 스크립트를 작성해야합니다. 액세스해야하는 시스템으로 이들을 푸시 아웃합니다.

또한 : 고객이 이것을 포기하도록 설득 할 수있는 한 가지는 새로운 개인 키가 이전 암호와 다른 암호를 사용하거나 심지어 암호를 가지고 있다고 강제 할 수있는 방법이 없다는 것입니다.

답변

첫 번째 질문에 대한 답변 : “기존 SSH 키에서 비밀번호를 변경할 수 있습니까?” 예입니다. openssh를 사용하면ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

문제는 암호가 개인 키 파일에 있거나 만료 날짜를 지원하지 않는 간단한 형식이라는 것입니다. 또한 ssh의 키 기반 인증 개념의 대부분은 개인 키가 중앙에서 관리되지 않으며 개인 키에 대해 암호 만료 정책을 시행 할 수없는 사용자의 워크 스테이션에만 존재해야한다는 것입니다.

대신 : 모든 환경에서 암호 정책이 해당 계정에 액세스하는 데 사용 된 방법이 아니라 사용자 계정 개체에 있기 전에있었습니다. 암호가 만료되거나 계정이 잠기면 ssh 키를 포함하여 모든 액세스 방법이 잠 깁니다.

계정에 대한 보안이 더 필요할 때 다단계 인증을 추가하십시오.

그러나 다른 사람들이 귀하의 유효한 우려를 해결하기 위해 무엇을했는지 궁금합니다.

답변

AuthorizedKeysCommand를 사용 하면 서버 측에서 일부 만기 메커니즘을 구현할 수 있습니다. 파일 타임 스탬프를 간단하게 검사하는 것부터 복잡한 것까지.

답변

충분하거나 충분하지 않은 한 가지 가능성은 SSH 사용자 CA를 사용하여 서명 된 키의 수명을 설정할 수 있습니다. 키 서명을 자동화하면 90 일 이상 서명을 거부 할 수 있습니다. 그런 다음, 사용자 CA의 공개 키를 / etc / ssh / sshd_config의 TrustedUserCAKeys에 추가하고 AuthorizedKeysFile을 none으로 설정하십시오.

답변

Hashicorp의 Vault 와 같은 도구를 사용하여 수명이 짧고 서명 된 SSH 키를 만들 수 있습니다 . 각 사용자는 매일 새로운 키를받습니다. LDAP 서버와 같이 오늘날 사용하는 모든 것을 사용하여 인증서를 얻으려면 Vault에 인증해야합니다.

이것을 설정하려는 노력은 거대하지 않지만 내 경험상 @Mark가 그의 의견에서 언급 한 것보다 큽니다. 기본적으로 한 문제 (무단 클라이언트 요구 사항)를 다른 문제 ( 샤드 관리 )로 바꾸고 있습니다.

그러나 내부 X509 인증서를 쉽게 생성하고 텍스트 파일의 데이터베이스 암호, 응용 프로그램 암호를 관리하는 것과 같은 다른 시나리오를 가능하게합니다. 노력과 ROI를 판단합니다.

또한 오픈 소스 버전에는 DR 기능이 없습니다 (다른 모든 기능이 있음).

답변

시간 기반 일회용 암호 (TOTP)를 통합 한 키 에이전트를 사용할 수 있습니다. 이제 “암호”가 1 분마다 변경됩니다.

그러나 여기의 다른 모든 사람들이 옳습니다. 이것은 바보입니다.

답변