방송에 쓰는 값을 모두 해시로 저장하면 될까요. 사용자가 보낸 식별자가 맞는지 대조할 때는 원래 값을 복원할 필요가 없습니다. 반면 미디어 서버가 SRT 연결에 사용할 passphrase는 원문을 다시 읽을 수 있어야 합니다. 둘을 모두 “스트림 키”로 부르며 같은 저장 규칙을 적용하면 어느 한쪽의 요구를 만족시키지 못합니다.
저는 PokeClip의 키 대조와 송출 비밀 사용을 나누고, DB에는 상태와 비밀 참조를 남기는 구조를 선택했습니다. 현재 Auth에는 passphrase의 PG 저장이 남아 있습니다. 원문을 Secrets Manager로 옮기고 DB에는 참조를 두는 방식으로 바꿀 예정이며, 이 전환을 준비 중입니다. 아래 내용은 2026년 10월 15일 판본에서 확인한 현재 구현과 변경 계획을 설명합니다.
대조할 식별자와 다시 읽을 비밀을 나눴습니다
streamid는 어떤 방송 경로를 사용하려는지 나타내는 불투명 식별자로 다뤘습니다. 사용자명·이메일을 담지 않고, 대조용 값은 DB에서 해시로 관리하는 설계입니다. SRT passphrase는 미디어 서버가 원래 값을 사용해야 하므로 단방향 해시만 보관할 수 없습니다.
이때 passphrase를 단순한 비밀번호 문자열 비교라고 설명하면 부정확합니다. SRT의 암호화 처리에서 키를 보호하는 비밀로 쓰이며, 세부 의미는 SRT 공식 소켓 옵션 문서에 설명돼 있습니다. 식별자와 이 비밀이 하는 일을 분리해야, streamid를 안다는 사실만으로 송출을 허용하지 않는 구조를 만들 수 있습니다.
| 데이터 | 필요한 연산 | 목표 저장 위치 |
|---|---|---|
| 대조용 streamid | 입력과 대조 | PostgreSQL의 해시 |
| 계정·활성 상태 | 조회와 변경 | PostgreSQL |
| SRT passphrase | 수신 경로에서 원문 사용 | Secrets Manager로 이전 예정 |
| 비밀을 가리키는 값 | 허용된 비밀 조회로 연결 | PostgreSQL의 참조 |
해시와 복원 가능한 저장 중 하나가 언제나 더 나은 것은 아닙니다. 대조에만 쓰는 값은 복원할 필요가 없지만, 원문이 필요한 연산까지 해시로 바꿀 수는 없습니다. 저장 기술보다 먼저 필요한 연산을 구분한 이유입니다.
공용 비밀은 단순하지만 폐기의 영향이 너무 컸습니다
모든 계정이 하나의 passphrase를 공유하면 관리할 값은 줄어듭니다. 그러나 하나가 유출되거나 폐기되면 전체 방송에 영향을 줍니다. 계정별로 송출 권한을 구분하려는 요구와 맞지 않아 이 대안은 제외했습니다.
PG에 KMS 봉투 암호화 값을 두는 대안도 비교했습니다. 이 경우 DB를 계속 사용하면서 원문을 암호화할 수 있지만, 애플리케이션이 암복호화와 비밀 수명 관리의 어느 부분을 책임질지 정해야 합니다. 저는 비밀의 수명과 접근 감사를 관리형 저장소에 맡기는 방향을 선택했습니다. Secrets Manager의 접근 제어·비밀 관리 기능을 활용하되, 계정이 그 비밀을 사용할 수 있는지는 애플리케이션에서 확인해야 합니다.
변경의 목적은 DB 조회 권한과 방송 비밀 조회 권한을 분리하는 것입니다. 계정 상태와 허용된 참조를 확인하고, 해당 작업의 IAM 역할로 필요한 비밀만 읽도록 옮길 예정입니다. 저장소를 바꾸어도 애플리케이션이 아무 비밀이나 조회할 수 있다면 이 선택의 목적을 이루지 못합니다.
현재 PG 읽기 경로를 바꾸는 작업이 남아 있습니다
2026년 10월 계정별 방송 연결을 조사하면서 실제 Auth가 passphrase를 PG에 저장하고 있음을 확인했습니다. 따라서 전환에는 원문 보관 위치뿐 아니라 이를 읽는 코드와 권한도 함께 바뀌어야 합니다. 현재 준비 중인 작업을 다음과 같이 나눴습니다.
| 변경할 부분 | 변경 뒤 확인할 조건 |
|---|---|
| 원문 보관 | Secrets Manager의 비밀을 실제로 사용하고 있는가 |
| DB 상태·참조 | 계정 상태와 참조가 올바른 비밀에 연결되는가 |
| 읽기 권한 | 필요한 작업 주체만 비밀을 조회할 수 있는가 |
| 병행 기간 | 기존 PG 데이터와 새 읽기 경로를 어떻게 취급하는가 |
표는 앞으로 확인할 조건이며 완료한 검사 결과가 아닙니다. 완료 시점이나 전체 연동 성공은 아직 확정하지 않았습니다. 과거에는 경로 조정자가 비밀 참조를 해석하는 방식을 검토했지만 계정별 방송 연결 방식은 이후 바뀌었습니다. 원문 저장 이전과 옛 조정자 구현은 별개의 작업으로 다루고 있습니다.
설계·조사·구현에는 AI 협업을 활용하고, 저는 저장 방식 선택과 현재 구현과의 차이를 확인하는 역할을 맡았습니다. 이번 변경에서 필요한 것은 보안 제품 이름을 하나 더 붙이는 일이 아닙니다. 대조만 할 값과 다시 읽을 비밀을 나누고, 실제 읽기 경로와 권한까지 그 구분을 따르게 만드는 일입니다.