16.7 보안 적용에 따른 성능 트레이드오프 관리

16.7 보안 적용에 따른 성능 트레이드오프 관리

방탄조끼를 입고 100미터 달리기 세계 신기록을 세울 수는 없다.
앞선 15장(보안) 에서 우리는 라우터에 TLS 암호화, 엄격한 ACL 검사, 세션 인증이라는 무거운 철갑을 세 겹으로 둘렀다. 그 결과, 지연 시간(Latency) 은 2배로 뛰고 대역폭(Throughput) 은 30%가 깎여나갔을 것이다.

이 장에서는 “보안이 곧 성능 저하“라는 편견을 부수기 위해, 하드웨어 암호화 가속기(AES-NI) 를 쥐어짜고 메모리 내 인증 캐시를 활용하여 보안과 속도라는 두 마리 토끼를 동시에 포획하는 아키텍트의 극한 타협안을 서술한다.

1. TLS/DTLS 암호화 오버헤드 측정 및 하드웨어 가속(AES-NI) 활용

TLS 를 켜는 순간, 평문(Plaintext) 대비 CPU 를 3배 더 먹는다. 암호화 연산 자체가 행렬을 곱하고 섞는 막노동이기 때문이다.

1.0.1 [인스펙션] 실리콘(Silicon) 브레이킹 전술

소프트웨어적인 꼼수는 없다. CPU 안에 내장된 암호화 전용 물리 칩(Hardware Accelerator) 을 강제로 두들겨 깨워야 한다.

1. 무자비한 하드웨어 가속 강제 (AES-NI)
인텔/AMD CPU 나 최신 ARM (라즈베리파이 4 이상) 에는 AES-NI (Advanced Encryption Standard New Instructions) 라는 칩이 박혀 있다.
Zenoh 에 연동된 OpenSSL 이나 Rustls 가 이 칩을 제대로 쓰고 있는지 lscpu | grep aes 로 확인하라. 만약 컨테이너(Docker) 환경이라서 이 칩셋 인식이 막혀있다면, 즉시 --privileged 나 디바이스 패스스루로 하드웨어 가속기를 컨테이너 안으로 멱살 잡고 끌고 들어와야 한다. (성능이 5배 빨라진다).

2. 초경량 스위트(Cipher Suite) 선별
성능이 떨어지는 에지(Edge) 기기에서는 최고 보안 등급(AES-256-GCM) 대신, 하드웨어 가속 효율이 극한에 달하거나 CPU 파이프라인 구조에 맞는 CHACHA20-POLY1305 로 강제 하향을 쳐라. 방탄 성능은 미세하게 뚫려도 런타임 레이턴시는 20% 이상 향상된다.

2. 세션 키 재협상(Key Renegotiation) 주기 최적화

TLS 커넥션은 한 번 맺을 때 수백 밀리초(Handshake Delay) 가 걸린다. 그런데 보안 강도를 높인다고 통신 중간중간 주기적으로 암호 키를 다시 만들어서 갈아 끼우면(Renegotiation) 스트림이 찰나의 순간마다 끊기게 된다.

2.0.1 [Runbook] 협상 타임아웃 지연 전술

1. 재협상의 악몽 (Jitter)
자율주행 자동차가 시속 100km 로 코너를 도는 0.1초 사이, 하필 그 타이밍에 라우터가 “자, 우리 암호키 새로 바꾸자(Key Rotation)” 고 핸드셰이크를 거는 참사가 발생할 수 있다. 이 핑퐁 동안 브레이크 명령은 소켓에 갇힌다(Jitter Spike).

2. 생애 주기(Lifetime) 튜닝
연결이 1시간 지속된다면, 로보틱스 같은 실시간 망에서는 과감하게 통신 세션 시작 시 만든 1개의 키를 연결 종료 전까지 통째로 우려먹도록 타협하라.
보안 부서가 “최소 10분에 한 번씩은 키를 갱신해야 규정 위반이 아닙니다” 라고 목을 조르더라도, 차량 제어 파이프(QoS RealTime) 와 로그 파이프(QoS Background) 의 TLS 커넥션을 물리적으로 두 개로 쪼개라.

  • 제어 파이프: 키 교체 주기(Rotation) 를 아예 무한대(Disabled) 로 해제하여 지터 방어.
  • 로그 파이프: 여기서만 5분에 한 번씩 규정대로 키를 갈아치움.
    이것이 성능과 컴플라이언스를 동시에 지켜내는 망 분리 아키텍처다.

3. 접근 제어 리스트(ACL) 평가 엔진 성능 최적화

초당 100만 번 Put 이 들어오면, 라우터는 100만 번 모두 “얘가 여기 쓸 권한이 있나?” 하고 방명록(ACL JSON) 파일과 문자열 대조 검사(Regex Matching) 를 수행해야 한다.

3.0.1 [인스펙션] 인메모리(In-Memory) 캐시 컴파일 전술

ACL 이 스루풋(Throughput) 이빨을 갉아먹게 내버려 두지 마라.

1. 와일드카드 정규식 컴파일링

  • 최악의 엔진: 패킷이 하나 들어올 때마다 robot/**/video 와 자기가 가진 키를 문자열 함수 match() 로 비교하는 것.
  • 최고의 엔진: 라우터가 켜질 때 ACL 의 규칙들을 모조리 하드웨어의 유한 상태 기계(FSM) 나 Trie 트리 구조로 미리 파싱(Compile) 해 메모리에 올려버린다. 이렇게 하면 문자열 비교 연산이 O(1) 해시 룩업(Hash Look-up) 으로 격하된다.

2. 통과 이력 캐시 (Pass-Through Cache)
“얘 방금 전에도 내가 허락해 줬잖아.”
로봇이 방금 권한 검사를 통과해 put 을 쏘고 갔다면, 바로 다음 1밀리초 뒤에 똑같은 아이디로 똑같은 토픽에 쏘는 put 패킷에 대해서는 전체 트리를 다시 훑지 않고, L1 수준의 짧은 생명주기를 가진 AuthZ_Cache 해시맵에서 “통과(True)” 를 즉시 반환하도록 Zenoh 플러그인 로직을 해킹하라.

4. 인증(Authentication) 절차 캐싱을 통한 연결 지연 감소

만약 외부 서버(Keycloak 연동 등) 로 사용자를 검증한다면?
로봇이 라우터에 connect 를 때릴 때마다, 라우터가 외부 HTTP API 외부 서버에 쿼리를 날렸다가 대답을 듣고 로봇을 들여보내 주는 끔찍한 네트워크 2중 대기가 발생한다. 연결 지연 시간 최소 500ms 확정이다.

4.0.1 [Runbook] JWT 토큰 검증의 분리 독립 전술

가장 빠른 인증(AuthN) 은 “누구한테 물어보지 않아도 스스로 아는 인증“이다.

1. 외부 의존성 절단과 JWT 의 채용
비밀번호(Password) 나 사용자 ID 기반으로 외부 데이터베이스를 조회하는 플러그인을 갖다버려라.
대신 비대칭 키로 서명된 JWT(JSON Web Token) 방식을 사용해야 한다.
로봇이 라우터에 JWT 하나를 내민다면, 라우터는 외부 서버망에 통신조차 연결하지 않고 자기가 로컬에 들고 있는 공개 키(Public Key) 하나만으로, 불과 10\mu s(마이크로초) 만에 서명 위조 여부를 독단적으로 결재 완료해 버린다.

2. 세션 티켓 회복(Session Resumption)
“지하차도에 들어가서 소켓이 끊겼다. 터널을 빠져나오자마자 다시 붙어야 한다.”
이때 처음 켰을 때처럼 500ms 의 긴 핸드셰이크를 치르면 센서 데이터가 이미 날아가 버린다. TLS 의 Session Resumption 기능을 켜서, 이전에 맺었던 비밀 정보를 캐싱해두어 단 1회의 핑퐁(0-RTT 또는 1-RTT) 만에 인증 절차를 패스하고 번개처럼 즉시 데이터를 쏘는 패스트 트랙(Fast Track) 을 구축해야 한다.