▲

AWS에서의 20년과 결코 내 일이 아니었던 적이 없던 시간

 (daemonology.net)
1P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • 2006년 Amazon S3 출시 직후부터 FreeBSD 보안 담당자로서 AWS 보안 구조와 무결성 문제를 지속적으로 제기하며 협력 시작
  • EC2 초기에는 커스텀 커널 제한과 Xen 보안성 우려가 있었으나, FreeBSD 실행과 보안 강화를 위한 제안이 장기적으로 반영됨
  • 2008년 이후 EBS, SimpleDB, IAM, IMDS 등 주요 서비스의 보안 취약점을 발견하고 Amazon과 함께 수정 및 개선 진행
  • FreeBSD/EC2 공식 지원 확립, AMI 빌드 통합과 UEFI 부팅 지원 등 기술적 통합을 주도하며 AWS 인프라 발전에 기여
  • 20년간의 협력은 외부 기여자와 AWS 엔지니어 간의 지속적 피드백과 신뢰 구축으로 이루어진 장기적 기술 파트너십의 사례임

AWS와의 20년: FreeBSD, 보안, 그리고 협력의 기록

  • AWS 초기와 보안 문제 제기

    • 2006년 4월 10일 Amazon S3 발표 직후 첫 AWS 계정을 개설하고 보안 백업 문제에 주목, 온라인 스토리지 개념에 매력을 느낌
      • 당시 활성화된 서비스는 Amazon Simple Queue Service와 Amazon E-Commerce Service 두 가지뿐이었음
    • FreeBSD Security Officer로서 AWS 요청은 서명되어 있었지만 응답에는 무결성 보호가 없다는 점을 지적
      • 당시 HTTP 기반 통신이 일반적이어서 응답 변조 위험이 존재했으며, 엔드 투 엔드 서명의 필요성을 강조

  • EC2 등장과 FreeBSD 지원 시도

    • Amazon EC2 출시 직후 FreeBSD 실행을 목표로 Amazon과 접촉, 2007년 초 첫 NDA 체결
      • EC2는 초기에는 커스텀 커널 불가였으나, 2007년 11월 Red Hat 지원과 함께 해당 기능이 추가됨
    • Xen 보안성에 대한 우려를 제기하고 보안 감사 필요성을 권고, Tavis Ormandy를 추천
    • EC2 인스턴스의 읽기 전용 루트 디스크와 메모리 초기화 기능을 요청, 이후 18년 뒤 EC2 Instance Attestation으로 구현

  • FreeBSD/EC2 기술적 도전과 협력

    • 2008년 Kip Macy가 FreeBSD를 Xen에서 PAE로 구동 성공, 이후 내부 AMI 도구를 FreeBSD로 포팅
    • Xen 3.0의 재귀 페이지 테이블 버그로 FreeBSD 부팅 실패, Amazon은 기존 고객 호환성을 위해 Xen 3.0 유지 결정
    • Elastic Block Storage 알파 초대, SimpleDB 서명 충돌 문제 발견 및 보고
      • Amazon은 Signature Version 2 설계 검토 요청 및 문서 수정으로 대응
    • SimpleDB의 NextToken이 직렬화된 Java 객체로 처리되는 보안 취약 설계를 보고했으나 초기에는 응답 없음

  • AWS와의 지속적 피드백과 보안 제안

    • 2008년 Amazon 입사 제안을 고려했으나 인터뷰에서 예외 처리 문제를 두고 논쟁 발생
    • 2009년 EC2 방화벽의 ICMP 차단으로 인한 Path MTU Discovery 실패 문제를 보고, 2012년에 수정
    • 2010년 NetBSD를 EC2에서 부팅 성공, 이후 t1.micro 인스턴스에서 FreeBSD 실행 성공
      • 2010년 12월 FreeBSD/EC2 지원 공식 발표
    • 이후 고객 요청으로 Cluster Compute 인스턴스 지원 확장, 2014년 T2 인스턴스 등장으로 “Windows tax” 회피 가능

  • AWS 내부 개선에 기여한 사례들

    • 2012년 S3 요청 오류를 추적해 데이터센터 라우터 하드웨어 결함을 발견, Amazon이 이를 교체
    • 첫 re:Invent에서 하이퍼스레딩 기반 RSA 키 탈취 연구를 공유, 이후 EC2 인스턴스가 2 vCPU 단위로 구성되는 계기 제공
    • 2015년 FreeBSD/EC2 AMI 빌드 과정을 FreeBSD 공식 릴리스 트리에 통합, 공식 지원 체계 확립

  • IAM과 보안 인터페이스 문제

    • 2016년 IAM Roles의 IMDS 자격 증명 노출 위험을 지적, “EC2’s most dangerous feature” 게시
      • 2019년 Capital One 침해 사건으로 해당 위험이 현실화, 이후 IMDSv2 도입
    • 2019년 AWS Heroes 프로그램에 선정되어 AWS 외부 기여자로 인정

  • 기술 발전과 FreeBSD 통합

    • 2021년 EC2의 UEFI 부팅 지원으로 FreeBSD 부팅 속도 7초 단축
      • BootMode=polyglot 요청이 2023년 “uefi-preferred”로 구현
    • 2023년 AWS Heroes Summit에서 Seekable OCI 보안 설계 결함을 발견, AWS Security 팀과 협력해 수정 진행
      • 2025년 2월 해당 기능이 대부분 고객에게 비활성화됨

  • FreeBSD Release Engineering과 AWS 협력

    • 2020년 FreeBSD Release Engineering 팀의 부책임자(Deputy Release Engineer) 로 임명
    • 2023년 Glen Barber의 퇴임 후 Release Engineering Lead로 승계, 연 4회 릴리스 체계 확립
    • 2024년 Amazon의 GitHub Sponsors 후원으로 주 10시간 지원을 받아 FreeBSD/EC2 유지보수 강화
      • 2025년 6월 “A year of funded FreeBSD”에서 성과 보고

  • 20년간의 협력과 감사

    • AWS 내부 시스템 접근 권한은 없었지만 Amazon 엔지니어들의 협력으로 수많은 기술적 문제 해결 가능
    • 내부 티켓 작성, API 로그 점검, 문서 확보 등에서 비공식적 지원 네트워크가 큰 역할
    • FreeBSD와 AWS의 발전은 개인 노력과 공동 협력의 결합으로 이루어진 결과임

함께 보면 좋은 글 β

▲
GN⁺ 15시간전  [-]
Hacker News 의견들

  • 저자는 ‘Heroes는 사실상 무급 Amazon 직원’이라는 농담을 했지만, 그건 농담이 아니라 현실임
    나는 내 개인 연구를 공개하지 않음. 이미 충분히 효율적인 가치 추출 머신에 무료 R&D를 제공하고 싶지 않기 때문임
    Amazon은 오픈소스의 경제적 전제를 무너뜨렸고, 그 결과 많은 프로젝트가 Business Source License로 전환하고 있음
    이런 개발자들은 Amazon이 얼마나 탐욕스러운지 알고 있음. 결국 커뮤니티 기여가 초거대 기업의 무급 노동으로 귀결되고, Amazon은 관리형 서비스로 사용자를 흡수해 원 프로젝트의 지원과 커뮤니티를 약화시킴

    • Amazon이 내 코드를 쓰는 게 싫다면, 라이선스에서 Amazon을 명시적으로 제외하면 됨
      “Amazon을 제외한 누구나 자유롭게 사용할 수 있다”라고 쓰면 Amazon은 법적 리스크 때문에 사용하지 않음
      다만 필요하다고 판단되면 Amazon은 자체 버전을 새로 만들 가능성이 있음
    • 대형 SaaS 기업들은 Business Source License가 있어도 API 인터페이스를 그대로 구현할 수 있음
      Redis 사례처럼, API 표면에 대한 법적 보호가 명확하지 않음
      예전에 Google v. Oracle 판례가 그런 보호를 세우려다 미뤄진 걸로 기억함
    • AGPL이나 GPL3 같은 라이선스도 사용할 수 있음. 이런 라이선스는 hyperscaler들이 거의 금지함
      사실 BSL을 택하는 회사들은 진정한 오픈소스 정신보다는 이미지 관리나 개발자 호감도 확보를 위해서만 공개했을 가능성이 큼
    • 나는 “운 좋게도” 이런 문제를 깊게 고민할 만큼 똑똑하거나 중요한 사람이 아님
      그래도 전적으로 동의함. 이제 내가 공개할 코드는 완전한 오픈소스이거나 완전한 비공개 둘 중 하나임
      누군가가 그걸로 돈을 벌 가능성이 있으면 공개하지 않음

  • 대기업에 시간을 주기 싫다는 시각을 이해하지만, 나는 다른 관점을 제시하고 싶음
    2006년에 내가 만든 프로젝트 이름을 2012년에 다른 개발자가 쓰고 싶다고 해서 흔쾌히 넘겨줬음
    그 프로젝트가 바로 scrypt, 개발자는 Colin이었음
    이런 커뮤니티 친절은 상업적 기대 없이도 쌓이는 좋은 업보가 됨

  • “Jeff Barr의 AWS 유저 밋업이 Second Life에서 열렸다”는 말이 참 흥미로움
    Second Life는 AWS의 초기 사용자였고, Jeff Bezos가 2005년 투자 라운드에 직접 참여했음
    그 덕분에 Jeff Barr가 Second Life 내에서 AWS 밋업을 열었고, 당시엔 Reuters나 Jonathan Coulton 같은 그룹들도 가상 공간에 진출하던 시기였음

    • 2002~2003년쯤 컨퍼런스에서 Second Life를 처음 봤을 때의 기억이 남음
      우리는 Evolution Robotics 부스로 나가서 ER1 로봇을 시연했는데, Second Life가 정말 인상적이었음
      좋은 추억으로 남아 있음
    • re:Invent 2020이 가상 공간으로 열렸을 때, Second Life 시절의 데자뷔를 강하게 느낌
      물론 노트북 화면 속 Second Life와 VR 헤드셋은 완전히 다른 경험이었음

  • “Amazon을 위한 무료 노동”이라는 프레임은 핵심을 놓치고 있음
    Colin은 자선활동을 한 게 아니라, Tarsnap이 FreeBSD/EC2에 의존하기 때문에 그걸 개선한 것임
    이런 모델이 오픈소스의 가장 건강한 형태임 — 자기 제품의 기반을 고치고, 그 결과가 모두에게 이익이 되는 구조임
    Amazon이 직접 관심을 가질 때까지 기다리는 건 영원히 기다리는 것과 같음

  • Amazon이 GitHub Sponsors를 통해 주 10시간, 1년간 후원했다는 글을 보고 놀랐음
    시간당 $300이라니, Google L6 엔지니어 급여 수준임
    지금은 더 받기를 바람

    • 미국 IT 업계의 시간당 요율은 정말 비정상적으로 높음
      독일어권 유럽에서는 120유로면 훌륭한 엔지니어를 구할 수 있음. 동유럽은 더 저렴함

  • IAM Roles for EC2에 대한 저자의 비판에 동의하지 않음
    IAM은 자격 증명을 정책 기반으로 관리하게 해주는 핵심 기능임
    Outlook, Slack, Teams보다 훨씬 안전하며, 수학적으로 팀원이 서명 키를 볼 수 없다는 걸 증명할 수도 있음
    Azure도 비슷한 개념을 적용해 MSSQL 접근을 깔끔하게 처리함

    • 나는 IAM Roles 자체를 반대하지 않음. 다만 역할 자격 증명을 전달하는 인터페이스로 최악의 선택을 했다고 봄
      예전엔 XenStore를 통해 커널에 자격 증명을 전달하자고 제안했음. Nitro 기반이라면 지금은 더 쉽게 구현 가능함
      커널이 자격 증명을 받아 소유권과 권한을 설정할 수 있는 가상 파일시스템으로 노출하면 됨
    • Scaleway는 포트 1024 미만에서만 토큰을 가져올 수 있게 함
      CAP_NET_BIND_SERVICE 권한이 있는 프로세스만 접근 가능하다는 점이 귀여움
      vsock(7) 소켓을 쓰면 속이기 어려운 연결 방식이 되어 더 안전함
      더 나아가 DMI 데이터에 부트스트랩 자격 증명을 넣으면 root만 읽을 수 있는 sysfs 디렉터리에 위치하게 됨

  • 2007년 이메일을 확인해보니, 초기에 AWS 서비스 접근을 개별 요청해야 했던 게 사실이었음
    처음엔 “Amazon E-Commerce Service”만 승인받았고, 이후 S3, EC2 베타 순으로 접근 권한을 얻었음
    당시 “Alexa Web Information Service”는 음성 비서가 아니라 웹 검색 API였음. 그 시절이 참 흥미로움

  • 정말 흥미로운 기술사적 기록임
    Tavis Ormandy 같은 유명 엔지니어도 인터뷰에서 실수할 수 있다는 점이 인상적임
    이런 경험담 블로그 글이 참 좋음

  • 20년 회고에 Hetzner나 OVH 언급이 없다는 게 의미심장함
    나는 AWS, Hetzner, 소형 클라우드를 함께 쓰는데, 가격 차이가 엄청남
    AWS는 월 $350, Hetzner는 20~25유로에 비슷한 스펙과 20TB 트래픽 포함임
    AWS가 파는 건 이제 컴퓨트가 아니라 IAM 모델, 글로벌 인프라, 조직 내 합의임
    “AWS를 선택하면 아무도 해고되지 않는다”는 인식이 진짜 제품임
    최근 AWS에서 워크로드를 옮긴 사람들에게 묻고 싶음 — 예상보다 더 고통스러웠던 부분은 무엇이었는지

답변달기