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
 - 태그
 - 분류
 - 회사
 - 맡은 업무
 - 개발
 - 주요 기술
 - 프로그래밍 언어