이 발표는 Active Record Encryption 구현 과정에서 겪었던 실제 문제점과 해결책에 대한 심도 깊은 사례 연구입니다. 특히 기존 암호화 전략에서 전환하거나 분산 시스템에서 작업하는 개발자들에게 유용하며, 암호화의 완벽성과 예상치 못한 난관에 대비하는 자세의 중요성을 역설합니다.
팀은 키 관리보다 분산 시스템에서의 키 배포 및 순환이 더 큰 난관임을 깨달았습니다. 여러 서버에 키를 동시에 배포할 수 없어 레코드 복호화 문제가 발생하자, ‘두 키 전략’을 도입하여 복호화 키 선 배포 후 암호화 키를 배포함으로써 평문 노출 없이 재암호화를 성공시켰습니다. 이는 시스템의 키 업데이트 역량 이해와 사전 테스트의 중요성을 강조합니다.
또한, Active Record Encryption은 키 ID, 헤더 등 추가 메타데이터를 포함하며, 사용자가 추가한 긴 태그 이름이 예상치 못하게 전체 레코드 크기를 크게 증가시켰습니다. 이로 인해 기존 컬럼 크기 조정 및 MySQL TEXT 타입 사용을 권장했습니다. 이는 메타데이터 추가 시 저장 공간 영향을 면밀히 분석해야 함을 보여줍니다.
마지막으로, 멱등성 문제와 예상치 못한 부작용에 직면했습니다. ‘특별한’ 컬럼 마이그레이션 시 changed_in_place 메서드가 항상 변경됨을 감지하여 실제 변경 없이 고객 감사 로그를 대량 생성하는 문제가 발생했으나, 해당 메서드를 Active Record encrypted type attribute에 위임하여 해결했습니다. encrypt 메서드의 이중 호출 버그도 발견했으나 멱등성 덕분에 심각한 문제로 이어지지는 않았습니다. 이는 일부 데이터는 특별한 주의가 필요하며, 모니터링보다 사전에 시스템 특성을 깊이 이해하는 것이 중요함을 시사합니다.
이러한 난관에도 불구하고, 팀은 서비스 중단 없이 원활한 컬럼 암호화 전략 배포에 성공했습니다. **키 순환 및 관리를 염두에 두고 시스템을 설계**하고, **컬럼이 암호화되어야 하는 이유와 해당 레코드에 미칠 수 있는 잠재적 부작용을 철저히 이해**하는 것이 핵심입니다. Active Record Encryption은 키 순환을 용이하게 하므로 적극 활용해야 하며, 자체적인 복잡한 키 순환 전략 구축은 피해야 한다고 조언합니다. 이 과정은 결코 쉽지 않았지만, 그 가치는 충분합니다.