보안
IronFlock은 보안이 선택 사항이 아닌 산업용 및 기업 IoT 환경을 위해 설계되었습니다. 시스템은 디바이스 연결에서 데이터 격리까지 모든 레이어에 걸쳐 심층 방어를 갖춘 제로 트러스트 아키텍처를 따릅니다.
디바이스에 열린 포트 없음
IronFlock을 실행하는 엣지 디바이스는 열린 포트를 노출하지 않습니다. 디바이스 에이전트는 WAMP 메시지 라우터로 모든 연결을 아웃바운드로 시작합니다. 이는 다음을 의미합니다:
- 디바이스 네트워크에서 인바운드 방화벽 규칙이 필요하지 않습니다.
- 디바이스는 인터넷에서 검색되거나 직접 주소 지정될 수 없습니다.
- 원격 접근은 역방향 터널을 통해 작동합니다 — 디바이스가 아웃바운드로 연결합니다.
이를 통해 디바이스가 열린 포트(SSH, HTTP, MQTT)에서 수신 대기하는 IoT 배포에서 일반적인 전체 공격 벡터 클래스가 제거됩니다.
인증
IronFlock은 사용자 인증에 **OpenID Connect(OIDC)**를 사용합니다.
다중 인증
모든 계정은 TOTP 기반 이중 인증(시간 기반 일회용 비밀번호)을 지원합니다. 사용자는 표준 인증 앱(Google Authenticator, Authy, 1Password 등)을 사용하여 계정 설정에서 2FA를 활성화할 수 있습니다.
API 키
프로그래밍 방식 접근을 위해 사용자는 REST API에 대해 인증하는 API 키를 생성합니다. API 키는 모든 작업이 실행되기 전에 백엔드를 통해 모든 요청에서 검증됩니다.
디바이스 인증
디바이스는 디바이스별 자격 증명으로 WAMP-CRA(챌린지-응답 인증)를 사용하여 인증합니다. 각 디바이스는 플래싱 프로세스 중에 고유한 시크릿을 받으며, 이는 디바이스에 저장되어 모든 후속 연결에 사용됩니다.
암호화된 전송
IronFlock의 모든 통신은 암호화됩니다:
| 연결 | 프로토콜 | 암호화 |
|---|---|---|
| 브라우저에서 IronFlock으로 | HTTPS | TLS 1.2+ |
| 디바이스에서 라우터로 | WSS(WebSocket Secure) | TLS 1.2+ |
| 서비스 간 | WSS | TLS(내부) |
| 데이터베이스 연결 | PostgreSQL SSL | TLS |
| 원격 접근 터널 | TLS를 통한 역방향 프록시 | TLS |
전체 시스템에 일반 텍스트 통신 경로가 없습니다.
메시징 격리
IronFlock은 모든 실시간 통신에 WAMP(Web Application Messaging Protocol)를 사용합니다. 메시지 라우터는 프로젝트 간 엄격한 격리를 시행합니다:
별도 렐름
각 프로젝트-앱 조합은 WAMP 라우터에서 자체 메시징 렐름을 갖습니다. 렐름은 완전히 격리된 네임스페이스입니다 — 한 렐름에서 게시된 메시지는 다른 모든 렐름에 보이지 않습니다.
이는 다음을 의미합니다:
- 프로젝트 A의 디바이스는 프로젝트 B의 메시지를 볼 수 없습니다.
- 프로젝트 A에 설치된 앱 X는 프로젝트 B에 설치된 앱 X와 다른 렐름을 갖습니다.
- 같은 앱이 두 프로젝트에 설치되어 있어도 데이터 흐름은 완전히 분리됩니다.
렐름 인증
모든 렐름 연결에는 인증이 필요합니다. 디바이스, 백엔드 서비스, UI 클라이언트는 렐름에 참여하기 위해 유효한 자격 증명을 제시해야 합니다. 승인되지 않은 클라이언트는 토픽을 구독하거나 프로시저를 호출할 수 없습니다.
데이터베이스 격리
각 프로젝트는 FleetDB(PostgreSQL)에서 자체 전용 데이터베이스 리소스를 갖습니다:
- 별도 테이블 — 각 프로젝트-앱 조합에는 자체 시계열 테이블 집합이 있습니다. 서로 다른 프로젝트의 데이터가 누출될 수 있는 공유 테이블이 없습니다.
- 별도 자격 증명 — 각 데이터 백엔드는 고유한 연결 자격 증명을 갖습니다. 앱은 자체 프로젝트의 데이터에만 접근할 수 있습니다.
- 프로젝트 간 쿼리 없음 — 데이터베이스 레이어는 쿼리가 프로젝트 경계를 넘을 수 없도록 시행합니다.
이 격리는 애플리케이션 수준뿐만 아니라 인프라 수준에서 시행됩니다. 손상된 앱도 다른 프로젝트의 데이터에 접근할 수 없습니다.
권한 시스템
IronFlock은 모든 프로젝트, 디바이스, 그룹, 앱, 대시보드, 데이터 백엔드가 자체 접근 제어를 갖는 자산별 권한 모델을 시행합니다:
- 자산의 소유자는 완전한 제어권을 가지며 다른 사용자에게 권한을 부여할 수 있습니다.
- 프로젝트 소유자는 해당 프로젝트 내 모든 자산에 대한 완전한 제어권을 자동으로 갖습니다.
- 각 권한은 별개의 불리언 플래그입니다 — 무제한 접근을 부여하는 광범위한 “관리자” 역할이 없습니다.
- 모든 권한 변경은 변경 불가능한 감사 추적에 기록됩니다.
자산 유형별 권한의 전체 목록은 접근 제어를 참조하세요.
소프트웨어 공급망 보안
보안은 소프트웨어가 어떻게 실행되는지에서 멈추지 않습니다 — 소프트웨어가 어떻게 빌드되고 전달되는지에서 시작됩니다. 디바이스에서 직접 실행되는 유일한 IronFlock 구성 요소인 IronFlock Supervisor는 강화되고 완전히 자동화된 공급망을 통해 빌드되므로, 사용자의 플릿에 도달하는 것이 정확히 무엇인지 신뢰할 수 있습니다.
- 최소한의 공격 표면 — Supervisor는 외부 런타임 종속성이나 내장 인터프리터가 없는 단일 정적 링크 Go 바이너리로 제공됩니다. 패키지 관리자도, 동적 라이브러리 트리도, 인바운드 연결을 수신 대기하는 것도 없습니다 — 공격자가 노릴 수 있는 대상이 극적으로 줄어듭니다.
- 지속적인 취약점 스캔 — 모든 릴리스는 바이너리가 실제로 실행할 수 있는 코드 경로에 초점을 맞춘 도달 가능성 인식 분석을 사용하여, 자체 코드 및 모든 종속성에 걸쳐 알려진 취약점(CVE)을 스캔합니다. 스캔은 매주 정기적으로 실행되기도 하므로, 버전이 출시된 이후에 공개된 취약점도 이미 배포된 빌드에 대해 여전히 드러납니다.
- 소프트웨어 자재 명세서(SBOM) — 각 릴리스는 바이너리에 들어간 모든 구성 요소와 버전의 전체 목록인 완전한 CycloneDX SBOM을 게시합니다. 이를 통해 사용자와 감사자에게 실행 중인 것에 대한 정확한 투명성을 제공합니다.
- 서명되고 검증 가능한 빌드 — 모든 릴리스 바이너리는 정확한 내용에 암호학적으로 바인딩된 sigstore 서명 출처 증명을 포함합니다. 이 서명은 변조 감지가 가능하고 독립적으로 검증할 수 있으므로, 바이너리가 IronFlock의 파이프라인에서 생성되었으며 전송 중에 변경되지 않았음을 확인할 수 있습니다.
- 게이트된 자동 릴리스 — 빌드, 서명, 게시는 개별 개발자의 머신이 아니라 통제된 CI 파이프라인에서 이루어집니다. 전체 자동화된 테스트 및 보안 스위트를 통과하지 않는 한 어떤 것도 게시되지 않으므로, 출시되는 아티팩트가 테스트되고 증명된 바로 그것임을 보장합니다.
- 안전한 무선(OTA) 업데이트 — OTA 업데이트는 암호화된 채널을 통해 전달되며 IronFlock이 게시한 서명된 빌드에서만 가져옵니다 — 따라서 디바이스는 인바운드 포트를 열거나 검증되지 않은 아티팩트를 신뢰하지 않고도 스스로 업데이트합니다.
이러한 제어들이 함께 작동하여 소스 코드부터 각 디바이스에서 실행되는 바이너리까지 검증 가능한 관리 연속성을 제공합니다.
규정 준수
IronFlock의 보안 아키텍처는 다음과의 규정 준수를 지원합니다:
- IEC 62443 — 산업 자동화 및 제어 시스템 보안
- ISO 27001 — 정보 보안 관리
- SOC 2 — 데이터 보안을 위한 서비스 조직 제어
- GDPR — EU 데이터 센터에 저장된 데이터(구성 가능), 데이터 접근에 대한 감사 추적
- EU Cyber Resilience Act (CRA) — 릴리스별 SBOM과 문서화된 지속적인 취약점 처리 프로세스는 디지털 요소를 포함한 제품에 대한 CRA의 핵심 의무를 직접적으로 충족합니다.
- SLSA / NIST SSDF — 서명된 빌드 출처와 게이트된 CI 파이프라인은 공인된 공급망 무결성 및 보안 소프트웨어 개발 프레임워크에 부합합니다.
암호화된 전송, 인증, 프로젝트별 데이터 격리, 세분화된 권한, 종합적인 감사 로깅, 강화된 소프트웨어 공급망의 조합이 이러한 프레임워크에서 요구하는 제어를 제공합니다.