꽤 긴 여정이었음. 자세한 내용은 작년 글에서 볼 수 있고, 인증서에 대한 새 글도 곧 올라갈 예정임
늘 그렇듯 FIPS 140-3가 필요한지 모르겠다면 필요 없는 것이지만, 정말 필요하다면 Go가 이를 달성하는 가장 쉽고 안전한 방법 중 하나라고 꽤 확신함. FIPS 140-3 규칙을 지키면서도 다른 사용자에게 제공하던 보안성과 편의성을 유지하는 일이 특히 어려웠지만, 꽤 잘 해냈다고 봄
특정 고객 환경에서 FIPS 준수가 필요한 대규모 bring-your-own-cloud 배포를 다루고 있는데, 아쉽게도 Go를 전혀 쓰고 있지 않음. 이 변화가 Go 도입의 계기가 될 수도 있겠음
현재 FIPS 준수는 BoringSSL 소스 트리를 쓰되 OpenSSL에 맞춰 컴파일하는 방식으로 가능했음. OpenSSL은 준수 상태이고, Red Hat이 RHEL에서 그렇게 하며 우리도 모든 워크로드에서 그 방식에 의존함. 기본적으로 https://github.com/golang-fips/go 와 같은 방식임
이번 새 방식은 전부 네이티브 Go임. 더 이상 OpenSSL이나 다른 우회가 아니라 그냥 표준 라이브러리로 해결됨
실제로 어떤 결과가 생길지 궁금함. 이제 Go가 일부 회사나 조직에 더 매력적인 선택지가 되는 건지, 아니면 순전히 보안 관련 변화인지 궁금함
보안 측면에서는 다운그레이드지만, 일부 정부 환경에서 사용할 수 있게 해줌
이제 미국 군산복합체 계약업체들이 Go 프로그래머를 더 많이 채용하고 그 기반으로 소프트웨어를 납품할 수 있음
전체적으로 보안에는 마이너스에 가깝다고 조심스럽게 봄. (X)ChaCha20-Poly1305 같은 현대적인 암호를 쓸 수 없기 때문임
우리 회사는 상용 제품과 정부용 제품을 모두 제공하는데, 후자에는 FIPS가 필수 요구사항임. Go 쪽은 Red Hat이 올바르게 처리해 주는 것에 의존하고, 그 결과 어느 환경에서도 쓸 수 있는 바이너리가 나옴
좋음. 예전에 Red Hat의 FIPS Go 빌드를 써서 배포한 적이 있는데, FIPS를 맞추기 위해 Go 스택 전체를 다른 버전으로 써야 하는 점이 늘 마음에 들지 않았음
미국 정부에 판매하는 많은 제품은 FIPS 사용이 요구되고, FIPS 버전과 비-FIPS 버전을 따로 만들고 싶어 하지 않으므로, 기업들이 Go를 도입할 수 있게 되는 데 큰 의미가 있음
Lobste.rs 의견들
꽤 긴 여정이었음. 자세한 내용은 작년 글에서 볼 수 있고, 인증서에 대한 새 글도 곧 올라갈 예정임
늘 그렇듯 FIPS 140-3가 필요한지 모르겠다면 필요 없는 것이지만, 정말 필요하다면 Go가 이를 달성하는 가장 쉽고 안전한 방법 중 하나라고 꽤 확신함. FIPS 140-3 규칙을 지키면서도 다른 사용자에게 제공하던 보안성과 편의성을 유지하는 일이 특히 어려웠지만, 꽤 잘 해냈다고 봄
Go는 BoringSSL을 쓰는 것 아닌가? 그걸 어떻게 FIPS 인증했는지 궁금함
이번 새 방식은 전부 네이티브 Go임. 더 이상 OpenSSL이나 다른 우회가 아니라 그냥 표준 라이브러리로 해결됨
실제로 어떤 결과가 생길지 궁금함. 이제 Go가 일부 회사나 조직에 더 매력적인 선택지가 되는 건지, 아니면 순전히 보안 관련 변화인지 궁금함
좋음. 예전에 Red Hat의 FIPS Go 빌드를 써서 배포한 적이 있는데, FIPS를 맞추기 위해 Go 스택 전체를 다른 버전으로 써야 하는 점이 늘 마음에 들지 않았음
미국 정부에 판매하는 많은 제품은 FIPS 사용이 요구되고, FIPS 버전과 비-FIPS 버전을 따로 만들고 싶어 하지 않으므로, 기업들이 Go를 도입할 수 있게 되는 데 큰 의미가 있음