Nebula 차단 목록: 배포하는 것은 당신이지 등대가 아니다

차단 목록 시행은 검사를 수행하는 호스트의 속성이지 검사받는 인증서의 속성이 아닙니다. 항목을 한 번도 읽어 들이지 않은 기계는 계속 그 신원을 받아들이며, 핸드셰이크 어디에도 두 피어가 서로 다르게 판단한다는 것을 알려 주는 것은 없습니다. 같은 노출된 자격 증명에 대한 저렴한 해법과 값비싼 해법은 적용 범위와 되돌릴 수 있는지에서 다르므로 의도적으로 선택해야 합니다. 아래 절에서는 항목이 하는 일, 어디로 전달해야 하는지, 교체가 더 나은 답인 경우, 그리고 둘 중 하나가 작동했음을 증명하는 방법을 다룹니다.

차단 목록 항목이 실제로 하는 일

PKI 구성은 인증서가 유효하게 서명되었고 만료되지 않았더라도 호스트가 거부해야 하는 지문을 나열합니다. 시행은 서비스가 시작될 때 그 호스트가 읽어 들인 목록을 기준으로 로컬에서 이루어집니다. 항목에 관한 어떤 것도 인증서 안을 이동하지 않으므로, 피어는 자신에게 제시된 자격 증명으로 그 결정을 알 수 없습니다. 등대는 피어가 서로를 찾도록 돕고 직접 경로가 실패한 곳에서 트래픽을 중계할 뿐이므로, 여기서 등대는 아무 역할도 하지 않습니다. 등대는 발견과 중계 계층이지 구성 배포 채널이 아닙니다.

기계 한 대를 갱신하면 그 기계의 결정만 바뀌고 다른 모든 피어는 정확히 그대로 남습니다. 서명 기관을 신뢰하고 항목을 본 적이 없는 피어는 무언가를 거부할 이유가 없습니다. 따라서 당신이 지켜보는 구성 요소는 목록을 시행하라는 요청을 받은 적이 없으므로, 등대를 지켜보며 폐기를 시험하는 것은 아무것도 증명하지 못합니다.

장치가 아니라 인증서를 식별하세요

호스트 이름, 장치 라벨, 현재 주소는 오늘의 기계를 식별하지만 다음 달에는 다른 것을 가리키므로, 거부하려는 자격 증명의 지문을 사용하세요. 그런 문자열은 어느 것도 차단 목록에 나타나지 않고, 어느 것도 재설치를 견디지 못합니다. 인증서를 출력하고 지문을 읽고, 그것이 폐기되는 자격 증명의 것이지 그 대체품의 것이 아닌지 확인하세요. 대체품이 이미 발급된 경우 옛 인증서와 새 인증서가 이름을 공유하면서 다른 모든 필드에서 다를 수 있으므로, 두 파일을 모두 읽는 것이 중요합니다.

어떤 지문을 언제 차단했는지 기록해 두면 나중 감사에서 완료된 변경과 의도된 변경을 구분할 수 있습니다. 항목이 하지 않는 일도 적어 두세요: 서명 기관을 무효화하지 않으며, 그 기관의 미래 인증서가 받아들여지는 것을 막지도 않습니다. 호스트 인증서 차단과 손상된 기관 교체는 결과가 다른 서로 다른 작업입니다.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

다른 구성과 똑같이 배포하세요

목록을 누군가 기억날 때 편집하는 파일이 아니라 전달 메커니즘을 갖춘 구성으로 취급하세요. 델타가 아니라 전체 목록을 밀어 넣어야 이전 갱신을 놓친 호스트가 빈틈을 쌓는 대신 따라잡습니다. Nebula PKI 문서가 정확히 그렇게 권하며, 그 조언은 수동 절차로 바꿔 말하기보다 그대로 따를 가치가 있습니다.

디스크의 파일이 바뀐 것만이 아니라 실행 중인 서비스가 내용을 다시 읽어 들였는지 확인하세요. 어느 기계가 변경을 적용했는지 추적하고 남은 목록을 비워질 때까지 보이게 유지하세요. 일주일 동안 닫힌 노트북은 그 결정을 배운 적 없는 피어이며 아무도 예상하지 못한 네트워크에서 다시 연결될 수 있습니다. 다음 폐기에서 그 방법을 다시 쓰고 첫 번째에서 절차가 디버깅되므로, 지문 옆에 전달 방법을 기록하세요.

차단 목록인가 기관 교체인가

차단 목록 항목은 좁아서 하나의 신원이 작동을 멈추고 나머지는 모두 계속됩니다. 서명 기관 교체는 넓어서 그 기관이 발급한 모든 인증서가 신뢰를 잃고 모든 호스트에 새 자격 증명과 새 신뢰 앵커가 필요합니다. 전자는 표적 폐기이고 후자는 마이그레이션이므로 서로 다른 승인과 서로 다른 유지보수 시간대가 필요합니다. 표는 둘을 적용 범위, 노력, 되돌릴 수 있는지에서 나란히 놓습니다.

잃어버린 노트북에는 피해 범위가 하나의 신원이고 잘못된 지문을 차단했다면 변경을 되돌릴 수 있으므로 차단 목록이 맞습니다. 유출된 기관 키에는 아직 발급되지 않은 인증서에 차단 목록이 도움이 될 수 없으므로 교체가 필요합니다. 그 양극 사이에서는 기관이 호스트 하나보다 크므로 노출된 자격 증명이 다른 무엇인가에 서명할 수 있었는지 물어보세요.

압박 속의 선택은 기본적으로 넓은 선택지를 낳는 경향이 있으므로 사고가 나기 전에 결정을 적어 두세요. 어느 경로를 택하든 남은 작업은 같습니다: 중요한 호스트에서 시행이 실제로 일어났음을 증명하는 것입니다. 그 시점에 지문과 날짜를 기록하는 것이 나중에 증명을 가능하게 합니다.

거부와 나머지를 확인하세요

차단된 신원에서 연결해 실패를 확인한 다음, 허가된 피어에서 연결해 여전히 필요한 것에 도달하는지 확인하세요. 모두를 끊는 변경은 성공적인 폐기가 아닙니다. 캐시된 상태가 결과를 숨길 수 있으므로 둘 다 새 세션에서 하세요.

변경 후에 이미 성립된 세션이 끝나는지 확인하고, 파일을 편집하면 무언가가 종료된다고 가정하는 대신 자신의 버전과 구성에서의 동작을 기록하세요. disconnect_invalid 옵션은 인증서가 만료되었거나 유효하지 않은 클라이언트를 포함하므로, 그것에 의존하기 전에 자신의 경우에 어떻게 적용되는지 확인하세요. 즉시 종료가 요구 사항이라면 그것을 별도로 시험하고 관찰한 내용을 기록하세요. 목록을 다음 재부팅까지만 시행하는 호스트에는 첫 시험이 감춘 전달 문제가 있으므로, 재시작 후에 시험을 반복하세요. 건강한 등대는 발견이 작동한다는 것을 알려 주지, 어느 피어가 정책을 적용했는지는 알려 주지 않습니다.