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


28

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

  1. 기존 SSH 키의 비밀번호를 변경할 수 있습니까?
  2. 그렇지 않은 경우이를 처리하는 데 사용할 수있는 도구가 있습니까? 생각 중이 야:

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

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

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


7
이 주제는 정보 보안에 대해 더 잘 논의 된 것 같습니다 . 기본적인 질문은 이미 거기에 대한 답변이 있습니다.
제랄드 슈나이더

31
이것은 실제로 GDPR에 필요하지 않습니다. GDPR에 따라 모범 사례를 따라야합니다. 그리고 오늘 가장 좋은 방법은 암호를 만료 하지 않는 것입니다. 암호 만료 기한은 세기 초반에 모범 사례 였지만 GDPR이 제안되기 전에는 불신했습니다.
MSalters

2
SSH는 인증서를 사용할 수 있습니다. 어쩌면 그런 것을 달성하는 데 사용될 수 있습니까?
Edheldil

예, @Edheldil이 말했듯이 만료 날짜를 추가 할 수 있으므로 원시 키 대신 인증서를 사용하십시오. 이에 대한 netflix 솔루션을 검색하십시오. 그들은 5 분 동안 유효한 인증서로 ssh 인증을 수행하는 내부 설정을 공유했습니다 (이는 인증에만 적용되며 열린 연결은 열린 상태로 유지됨).
Patrick Mevzek

9
@GeraldSchneider의 기본 질문은 "고객은 바보입니다. 최소한의 노력으로 고객이 원하는 것을 어떻게 줄 수 있습니까?"입니다. InfoSec 질문이 아니라 ServerFault 질문입니다.
Mark

답변:


35

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

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

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

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

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

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

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

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


10
언급 한 바와 같이,이를 수행하는 올바른 방법은 수동 이며 수동 노동에 대해 상기 고객에게 청구하는 것은 충분한 억제책이 될 수 있습니다.
감독

3
"이 작업을 수행하지 마십시오"를 고객에게 알리는 좋은 방법은 "물론 직원이 키를 업데이트하는 프로세스에는 이전 키가 영구적으로 삭제된다는 보장이 포함되어야합니다. 이전 공개 / 개인 키 쌍이 잘못된 손에 들어 가지 않습니다.이를 보증 할 수 없으면이 계획을 진행할 수 없습니다. "
Max Williams

19

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

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


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

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


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


6
또한, PW 회전이 pw의 도난 / 브루 토포스를 방지하기 위해서는 키 손실 / 도난을 방지하기 위해 키 대신 암호 대신 키를 회전해야합니다. 공격자가 이전 암호로 이전 개인 키를 가져와도 여전히
침입

@BlueCacti 원래 비밀번호 / 구절이 이미 많은 양의 엔트로피를 가진 선택 프로세스를 기반으로 한 경우 강제 비밀번호 순환은 실제로 의미가 없습니다. 1M 년이 걸릴 수있는 암호를 변경하여 같은 양의 암호가 필요할 경우 다른 암호를 사용하면 실제로 아무 것도 개선되지 않습니다.
code_dredd

@code_dredd 저는 비밀번호 순환 사용에 대해 이야기하지 않았습니다. 나는 그것에도 반대하고 있습니다. OP의 질문과 관련하여이 경우 키의 암호를 회전하는 것보다 키를 회전하는 것이 더 의미가 있다고 지적하고 싶습니다.
BlueCacti

@BlueCacti 나는 당신이 말한 것에 추가 할 몇 가지 사항만을 언급했습니다. 나는 아무 것도 논의하고 있지 않습니다.
code_dredd

2
다단계 인증의 경우 +1 그런 다음 잘 알려진 앱 / 플러그인을 사용하여 코드를 생성하십시오. 그렇게하면 X 초마다 암호 변경 사항을 클라이언트에게 알릴 수 있습니다. 여기에 링크를 가능한 구현으로 포함시키는 것은 어떤 종류의 보증도 아닙니다. digitalocean.com/community/tutorials/…
Philippe

6

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


개인 키의 암호를 변경할 때 공개 키가 변경되지 않습니까? 암호가 변경되었는지 어떻게 확인합니까?
Edheldil

당신은 할 수 없습니다. 제안한대로 개인 키 암호 문구를 변경해도 공개 키에는 영향이 없습니다. 심지어 암호문을 모두 제거 할 수도 있습니다. 공개 키 전체가 변경되었는지 여부 만 확인할 수 있습니다.
guzzijason

6

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


2

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

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

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

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


1

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.