
Eyevacs4




- React Native Codepush 적용을 통해 배포 시간 1000%가량 단축
- Gitflow 적용을 통한 개발 흐름에 중단되지 않는 hotfix 등의 전략 적용
- Open API Spec을 활용하여 API 변경사항 트래킹 및 인터페이스 Auto Create 되도록 하여 실수 방지
- 자사의 다른 제품군과 계정 통합 작업 진행
- AWS CloudWatch 비용 최적화
- 결제 관련 Micro Service Replica 가능하도록 구축
- 클라우드 환경에서 동작되던 인프라를 고객사의 요구사항에 맞게 Bare metal 에 직접 구축
- 로그 수집 및 메트릭 수집 기능 포함
- replica 불가능한 서비스 replica가 가능하도록 Architecture Migration
- 미국 현장 납품을 위한 Language i18n, timezone 시스템
- ECS 비용 최적화
- MSA 환경에서 권한 인증 시스템
- IPC

✅ 핵심 문제
- IoT 장비(Arduino, ESP32 등)는 TLS 통신을 위해 CA 인증서를 펌웨어에 포함함.
- CA 인증서가 만료되면 TLS 연결 실패 → OTA 펌웨어조차 내려받지 못함 → 벽돌 위험
✅ 일반적 접근
- CA를 갱신한 펌웨어를 OTA로 배포하여 문제 해결
- 하지만 TLS 실패로 OTA 자체가 불가능해지면 순환 참조 발생
✅ 대응 전략
방법 | 설명 | 장점 | 단점 |
1. OTA용 HTTP fallback | OTA만 HTTP 허용 | 쉽게 복구 가능 | 보안 약함 |
2. OTA 시 TLS 인증 무시 | OTA 시 TLS 검증 생략 (setInsecure()) | 업데이트 가능 | 보안 취약 |
3. CA를 외부 저장소에 둬서 OTA로 교체 | 펌웨어 일부만 교체 가능 | 유연, 안전 | 구현 복잡 |
4. Public Key Pinning | 서버 공개키만 비교 | 중간 CA 변화 대응 | 키 갱신 어려움 |
5. TLS Offloading Gateway | 게이트웨이가 TLS 처리 | 단말 경량화 | 인프라 필요 |
✅ 인증서 체인 교체 시 서버 대응
- 서버는 동시에 여러 체인을 제공할 수 있음
- 구형 클라이언트: 이전 루트 CA 체인 사용
- 신형 클라이언트: 신규 루트 CA 체인 사용
- 이를 크로스서명(chain switching) 이라고 함
- Nginx/Apache에서는 fullchain.pem으로 구성 가능
- AWS ACM은 제한적이라, 프록시 서버가 필요할 수도 있음
✅ 결론
- CA 만료 = OTA 단절 위험이므로,
- OTA fallback 경로 설계 + 인증서 교체 방식 관리가 매우 중요함
- 가장 현실적인 조합:
- TLS 보안 유지하면서 OTA만 fallback 허용 (HTTP or 인증 생략)
- 무결성 검증(SHA256 or ECDSA) 반드시 적용
- 서버는 다중 체인 구성하여 구형/신형 동시 대응
- 날짜
- 2023-08-01
- 태그
- 분류
- 회사
- 맡은 업무
- 개발
- 주요 기술
- 프로그래밍 언어