Q> 회사에서 정보시스템 개발을 Microservice Architecture로 한다고 하는데 정보보안 관점에서 고려사항에 대한 문의
회사에서 기술적 파트의 정보보안 업무를 담당하고 있습니다. IT부서에서 정보시스템 개발을 Microservice Architecture를 기반으로 하겠다고 합니다.
관련 자료를찾아 보았지만 개념적인 내용들이 대부분이고 IT개발부서에 구체적으로 어떤 내용들을 보안 요구사항으로 제시해야 하는지 도움을 요청합니다.
A>
<> Microservice Architecture의 보안 요구사항
당사가 금융회사들을 중심으로 Microservice Architectur기반의 정보시스템 개발에 대한 개발보안 컨설팅들을 수행하면서 6개 영역 48개의 표준 보안요구사항을 정리하였다.
Microservice Architecture는 별도의 Service Port를 제공하는 Docker Container로 다수의 Microservice들을 구현하기 때문에 인증, 접근권한, 로깅, 암호화, 개인(신용)정보보호 등 거의 모든 부문의 정보보안 아키텍처를 다른 시각에서 재조명 해봐야 한다.
외국은행의 경우 약 1,500개의 Microservice로 구성된 사례도 있는 것을 고려해볼때, 그 복잡성과 다양성을 kubernetes의 Orchestration와 같은 전용 도구로 자동화 하지 않으면 관리자체가 어렵게 된다. 또한, API Gateway를 이용하여 인증, 로깅, 암호화 등을 중앙집중화하고 CI/CD 도구에 취약점 분석 Plugin을 연동하여 Shift Left전략을 쓸수 밖에 없는 구조를 가지고 있다.
이러한 보안요구사항의 구체적인 실무 가이드를 개발하여 활용하고 있으며 모든 문서들을 지속적으로 업데이트하고 있다.
| 영역 | 요구사항 갯수 |
|---|---|
| 1. 통합관리 관련 요구사항 | 13개 |
| 2. 인증관련 요구사항 | 14개 |
| 3. API Key와 서명요청 관련 요구사항 | 7개 |
| 4. 배포 관련 요구사항 | 4개 |
| 5. 데이터 및 메시징 권한 제한 | 6개 |
| 6. 모니터링 및 로깅 관련 요구사항 | 4개 |
| 합 계 | 48개 |
1. 통합관리 관련 요구사항
1.1 승인된 Application Container만 사용하도록 통제
| Microservice Architecture는 서비스의 개수와 복잡성이 늘어나기 때문에 공격자 입장에서는 전체 시스템의 공격 가능범위가 확대될 수 있다. 따라서 Attack Surface를 최소화하는 방안으로써 승인된 Application Container만 사용하도록 통제해야 한다. |
1.2 Container의 환경을 최신 및 안전한 상태로 유지
| 시스템 관리자는 컨테이너의 실행 환경이 최신 상태로 지속적으로 유지되도록 해야 한다. 조직의 정책에 따라 Container의 환경을 최신상태 및 안전한 상태로 유지해야 한다. |
1.3 Container 보안설정
| Container에 대한 보안설정을 적용한다. 예를 들어서 Docker Container 19.03 이상 버전에서 지원되는 Non-root(또는 Rootless) 설정 등과 같이 Container 보안에 대해 공신력 있는 안내서나 가이드에 따라 보안설정을 적용한다. |
1.4 IP Filtering기술을 적용하여 특정 IP 주소 또는 IP주소대역으로 접근통제
| Host에서 실행되는 Microservice의 연결성을 제어하기 위하여 IP Filtering 기술을 필수적으로 적용해야 한다. IP Filtering기술을 적용하면 특정 IP 주소 또는 IP주소대역으로 접근을 허용하거나 제한할 수 있기 때문에 무분별한 접근을 방지하고 Microservice의 안전을 확보할 수 있다. |
1.5 API Gateway를 통한 서비스 구성
| Microservice 간의 통신(East-West통신)은 API Gateway를 통해서 이뤄지도록 하여 인증, 권한, 로깅 및 알림 기능을 구성해야 한다. Gateway를 통해 통신하면 모든 트래픽이 중앙집중화 되기 때문에 인증관리, 권한관리, 로깅관리, 알림관리 등과 로드밸런싱을 구현할 수 있다. |
1.6 Container 서비스 포트 최소화
| Microservice를 호스팅하는 Container는 단일포트 또는 서비스제공에 필요한 최소한의 Service Port로 제한되어야 하며 나머지 모든 서비스포트들은 명시적으로 차단하여 잠재적인 보안 위험요소를 줄일 수 있다. |
1.7 서비스간 통신 모니터링 및 시각화 도구 확보
| Microservice는 서로 다양한 방법으로 통신하므로 서비스간 통신의 패턴과 복잡성을 모니터링하고 시각화 하는 도구를 운영해야 한다. Microservice의 복잡성을 관리하기 위한 도구이며 서비스의 Health check를 점검하고 잠재적 문제요소 또는 효율성 저하요소를 신속하게 탐지할 수 있다. |
1.8 통신모니터링 도구 구축 및 임계값 구성
| Microservice 환경의 통신들을 모니터링하고 이상징후를 신속하게 탐지하기 위하여 정상적인 통신양들에 대한 기준선을 설정하고 트래픽 급증이나 비정상적인 통신흐름과 같은 이벤트가 감지될 때 알림이 발생하도록 모니터링 도구의 임계값이 구성되어야 한다. |
1.9 개발계, 테스트계, 운영계의 논리적 네트워크 분리구성
| 개발계, 테스트계, 운영계는 논리적으로 별개의 네트워크로 분리되어야 한다. 이는 개발계, 테스트계, 운영계의 목적이 상이하므로 각각 별도의 네트워크에서 실행함으로써 잠재적인 오류나 보안위협이 다른 환경으로 확산되는 것을 방지할 수 있다. |
1.10 API의 목록과 그 특성들을 공개
| 소프트웨어를 사용하는 개발자들이 서비스를 사용하기 위한 기능, URI 및 기타 특정 요구사항을 명확하게 이해할 수 있도록 API의 목록과 그 특성들을 공개한다. 그러므로써 해당 API를 사용하는 개발자들은 더 효과적이고 안전한 방식으로 서비스와 상호 작용할 수 있다. 특히, 기능, URI, 그리고 기타 요구사항 등의 중요한 정보를 인지함으로써 잘못된 사용이나 오류를 줄일 수 있게 된다. |
1.11 자원사용량과 성능의 지속적으로 모니터링을 위한 시스템 구축
| Microservice의 자원사용량과 성능을 지속적으로 모니터링하여 자원에 대한 과도한 요청이나 예기치 않은 사용량 급증을 신속하게 파악해야 한다. 자원사용량 급증이 발생할 경우, 용량관리를 통해 추가적인 자원을 할당하거나, 기존의 리소스 사용을 최적화하여 서비스의 안정성을 유지할 수 있다. |
1.12 심층방어 전략으로 Microservice 보호
| Microservice는 심층방어(Defense in Depth)전략으로 보호되어야 하며, 이에는 통신흐름의 필터링, Microservice 접근을 위한 인증 및 권한부여, 암호화 기술 등이 포함되어야 한다. 즉, Microservice를 보호하기 위해 통신 흐름을 필터링하여 원치 않는 접근을 차단하고, 사용자나 시스템이 Microservice에 접근할 때 그들의 신분을 인증하며 적절한 권한 을 부여해야 하며 데이터의 기밀성과 무결성을 보장하기 위해 암호화 기술이 사용된다. |
1.13 API Gateway에서 민감정보 보관 금지
| API Gateway에서 트래픽을 검사하거나 분석하는 기능작동 이외에는 메모리에 개인(신용)정보와 같은 민감정보를 오랜 시간 동안 보관하지 않아야 한다. 이는 개인(신용)정보와 같은 민감정보의 유출이나 관련법이나 제도의 위반의 위험성이 있기 때문이다. |
2. 인증관련 요구사항
2.1 인증관련 표준을 SW개발주기 초기단계에 정의
| Microservice의 인증모델은 S/W 개발주기의 초기단계에 정의하여 보안 위반의 위험을 줄이고 효과적인 인증 방식을 확립해야 한다. 연합된(여러 도메인 및 애플리케이션에서 사용자의 신원과 권한을 공유하는 방식) 신원인증으로 다양한 시스템 및 애플리케이션 간의 접근 제어를 단순화하는 경우에도 인증관련 보안표준을 준수하고 신뢰성 있는 방식으로 서비스가 동작되도록 보장되어야 한다. |
2.2 인증기술은 JWT와 같은 오픈 표준 프로토콜을 이용
| 인증기술은 JWT, OAuth 2.0과 같이 잘 알려진 안전한 오픈 표준 프로토콜을 이용해야 한다. MSA에서는 일반적인 Access Token방식과 다르게 사용자의 인증정보를 가지고 있는 JWT(Json Web Token)을 표준으로 사용한다. API Gateway 환경에서 사용자 또는 시스템이 JWT를 첨부하여 API Gateway를 통해 서비스에게 명령을 요청하고 서비스는 API Gateway가 첨부한 사용자 인증정보를 기반으로 요청을 처리한다. |
2.3 Token기반 인증 메커니즘은 안전한 암호화 알고리즘을 사용
| Token기반의 인증 메커니즘은 암호화 관련 가이드에 따라 안전한 암호화 알고리즘을 사용해야 한다. Token생성을 위해 사용되는 암호화 알고리즘의 안전성 확보, 키관리 및 기타 보안조치를 확보함으로써 Token기반의 인증의 보안성을 강화한다. |
2.4 동시인증 허용 최소화 및 최대한계 설정
| 서비스의 사용성과 보안성을 강화하기 위하여 사용자 또는 프로세스가 동시에 여러 인증을 사용할 수 있도록 허용하되 동시 인증의 최대한계를 엄격하게 설정하여 대량의 가짜인증 요청과 같은 잠재적 위험을 방지해야 한다. |
2.5 Replay Attack 방지를 위해 인증토큰에 TTL(생존시간) 설정
| 인증 토큰은 Replay Attack을 방지하기 위하여 TTL을 설정해야 한다. 토큰에 TTL(생존시간)을 설정함으로써, TTL이 지난 만료된 토큰을 식별하여 이전에 사용된 유효한 세션을 재사용하는 Replay Attack을 방지할 수 있다. |
2.6 토큰 재검증시마다 TTL의 새로운 만료시간 업데이트
| 인증 토큰의 TTL(생존시간)은 토큰이 재검증될 때 마다 새로운 만료시간으로 업데이트되어 토큰의 보안을 강화해야 한다. 사용자 또는 시스템이 계속해서 서비스를 활성 상태로 사용하고 있다면, 토큰은 재검증 과정에서 새로운 TTL로 연장된다. 그러나 만약 사용자 또는 시스템이 서비스를 이용하지 않게 되면, 초기에 설정된 TTL에 따라 토큰이 만료되기 때문에 사용자가 활성 상태인 동안 서비스 중단 없이 활동을 계속할 수 있게 하면서도, 장기간 비활성 상태의 토큰은 자동으로 만료시켜 보안을 유지하게 된다. |
2.7 만료된 토큰의 차단 및 오류코드 반환 처리
| 기간이 만료된 토큰은 인증요청시 차단되어야 하며 사용자에게 적절한 HTTP 오류코드(예:401)을 반환하도록 구현해야 한다. 만료된 토큰을 허용하면 보안 문제가 발생할 수 있으므로, 만료된 토큰으로의 인증 요청은 차단되어야 한다. 만약 시스템이 만료된 토큰의 인증 요청을 감지하면, 사용자에게 HTTP 401 오류 코드(“Unauthorized”)를 반환하도록 구현한다. |
2.8 만료된 토큰은 메모리에서 삭제처리
| 만료된 토큰은 메모리에서 정기적으로 삭제되어야 한다. 메모리내에 만료된 토큰을 보관하는 것은 불필요한 자원소모를 가져올 뿐만 아니라 잠재적인 보안 취약점으로 악용될 수 있으므로 시스템의 효율성과 안전성을 유지하기 위해, 만료된 토큰은 정기적으로 메모리에서 제거되어야 한다. |
2.9 위임받은 요청에 대한 재사용 방지 처리
| OAuth인증과 같이 다른 사용자나 서비스로부터 권한을 위임받은 요청을 악의적으로 재생할 수 없도록 조치되어야 한다. Replay Attack은 악의적인 사용자가 이전의 유효한 통신을 캡처하고 그것을 다시 서버에 전송하여 정보나 서비스에 액세스하려는 시도이며, 위임받은 요청이 재사용되는 것을 방지하는 것이다. |
2.10 JWT인증서 교환시 PKI모범사례 준수
| JWT를 인증에 사용할 때, 인증서 교환을 위해 PKI의 모범사례를 준수해야 한다. JSON 웹 토큰(JWT)은 클레임 기반 정보를 포함하며, 이를 사용한 인증에서 인증서 교환을 할 때 PKI의 모범 사례를 따름으로써 안전성을 확보하는 것이다. |
2.11 인증 토큰의 암호화 적용
| 인증 토큰은 토큰 유출시에도 위험을 최소화하기 위하여 암호화되어야 한다. 인증 토큰은 인증 및 권한 정보를 갖고 있으므로 악의적인 사용자에게 노출될 경우 보안위협이 발생할 수 있다. 따라서, 토큰이 탈취되더라도 그 내용을 쉽게 해독하기 어렵도록 암호화하여 위험을 최소화하는 것이다. |
2.12 Gateway에서 모든 API Endpoint를 인증 처리
| 모든 API endpoint는 Gateway에게 인증되어야 한다. API endpoint의 모든 통신은 Gateway를 통해 이뤄지기 때문에 Gateway에서 인증함으로써 유효하지 않거나 악의적인 요청이 시스템 내부로 침투하는 것을 방지함으로써 중앙 집중식 인증 메커니즘으로 전체 시스템의 보안 수준을 강화하는 것이다. |
2.13 Gateway의 인증관리기능에서 인증 실패횟수 제한 설정 및 알림설정
| Gateway는 인증 실패횟수를 제한하고 반복된 인증실패를 알리는 메커니즘이 구현되어야 한다. 여러 차례의 인증 실패는 악의적인 사용자나 시스템의 무차별 대입 공격(brute force attack)을 시도하고 있음을 나타낼 수 있으며 이런 위협을 효과적으로 대응하기 위해 게이트웨이는 연속된 인증 실패를 감지하고 해당 횟수를 제한하는 기능과 상황을 관리자나 관련 담당자에게 알림을 보내, 즉시 대응할 수 있게 해야 한다. |
2.14 예외적으로 비밀번호 사용시 비밀번호 정책 준수
| 예외적으로 비밀번호 사용이 불가피하게 필요한 경우 조직의 내부정책과 절차에 따라 허용하되 비밀번호의 강도, 생성부터 폐기, 정기적인 점검 등을 적용하여 오남용을 방지해야 한다. |
3. API Key와 서명요청 관련 요구사항
3.1 전송 데이터에 대한 무결성 메커니즘 구현
| 서비스는 전송된 데이터가 전송 중에 변경되지 않았는지 확인하기 위해 데이터 무결성 메커니즘을 구현해야 한다. 서비스는 전송된 데이터의 무결성을 확인하기 위한 메커니즘, 예를 들면 Checksum이나 Hash 검증 등의 방법을 사용하여 데이터가 전송 중에 조작되지 않았는지 검증해야 한다. |
3.2 서비스간 통신방식에 인증 및 암호화 적용
| 서비스간의 통신방식(Microservice 또는 응용프로그램간 함수호출 구조)는 공격자가 네트워크에서 API Call을 가로채서 서비스를 공격할 수 없도록 안전한 채널을 통해 이뤄져야 하며, 적절한 인증 및 암호화 메커니즘을 적용해야 한다. |
3.3 API Key는 고유값의 서비스 ID, 사용자ID로 구성
| 개별 서비스가 다른 서비스를 호출하기 위해 고유한 API Key를 갖도록 해야 하며 이 Key는 최소한 고유한 값의 서비스ID와 사용자 ID로 구성되어야 한다. API 키의 고유성은 서비스 간의 통신 보안을 강화하는 중요한 요소이므로 서비스마다 고유한 API 키를 사용함으로써, 각 서비스의 인증 및 권한 부여를 정확하게 관리할 수 있다. 또한, 키가 서비스 ID와 사용자 ID로 구성되면, 이를 통해 서비스 요청이 어느 서비스에서 오는지와 어떤 사용자에 의해 실행되는지를 정확하게 식별할 수 있게 된다. |
3.4 API Key송수신 구간에 암호화(TLS)적용
| API Key 통신은 전송구간 암호화(TLS)를 사용해야 한다. API key는 서비스 간의 인증과 권한 부여를 위한 중요한 정보이므로 Key가 송수신 중에 외부의 악의적인 공격자로부터 보호되어야 한다. 송수신 암호화(TLS)는 데이터가 네트워크를 통해 전송될 때 외부의 침입자로부터 안전성을 확보할 수 있으며 데이터의 기밀성과 무결성을 보장한다. |
3.5 모든 API요청에 암호학적 서명 적용
| 모든 API요청은 암호학적으로 서명되어야 하며 이 서명에는 최소한 요청 매개변수 데이터, 서비스 ID, API 키, 그리고 원본 타임스탬프를 포함해야 한다. API 요청이 암호학적으로 서명됨으로써 해당 요청의 무결성 및 출처를 검증할 수 있게 되며 서명에 여러 정보를 포함함으로써, 요청이 중간에 변경되거나 조작되었는지를 확인할 수 있다. 특히, 요청 매개변수 데이터, 서비스 ID, API 키와 같은 중요한 정보가 서명에 포함되어야 하므로, 요청의 무결성 검증이 훨씬 강화된다. 원본 타임스탬프는 요청의 TTL(생존시간)을 확인하고 재생 공격을 방지하는데 도움을 줍니다. |
3.6 서비스 개발에 사용되는 함수는 SDK를 사용하여 생성
| 서비스개발을 위해 사용되는 함수는 승인된 SDK를 사용하여 생성되어야 한다. 승인된 SDK를 사용함으로써 개발자가 검증되고 안전하다고 판단된 도구들을 사용하여 코드를 작성하도록 하여 개발되는 소프트웨어의 안정성과 보안성을 보장하는 것이다. |
3.7 Microservice개발시 보안표준을 준수
| Microservice 개발시에는 OWASP, SANS, 시큐어코딩 가이드, 전자금융기반시설 취약점 평가기준 등 관련 보안표준 지침이나 안내서를 따라야 한다. 이를 준수함으로써 Microservice의 보안성과 안정성을 향상시킬 수 있다. 대부분의 조직은 Jenkins 등으로 CI/CD 시스템을 구축하여 Microservice의 Plan-Code-Build-Test-Release-Deploy-Operate 모든 단계를 자동화로 운영하고 있으며, 보안취약점 관련 도구들을 Jenkins Plugin으로 연동함으로써 Shit Left전략을 적용하고 있다. |
4. 배포 관련 요구사항
4.1 배포관리 정책은 Orchestration으로 자동화 방식 적용
| Microservice 또는 Container화된 애플리케이션의 배포와 관리에 대한 정책구성은 Orchestration 절차의 일부로 세분화를 강제하기 위해 자동화된 방식으로 적용되어야 한다. 오케스트레이션 도구가 정책을 자동으로 적용하여 시스템 간의 세분화(또는 분리)를 보장하도록 오케스트레이션 프로세스를 통해 자동화된 방식으로 정책을 적용함으로써, 인프라의 일관성을 유지하고, 수동 설정에서 발생할 수 있는 오류를 최소화하며, 보안 요구사항을 철저히 준수할 수 있다. |
4.2 Microservice의 모든 구성요소는 최신 보안 업데이트 적용
| Microservice가 원활하게 동작하기 위해 필요한 모든 구성요소들은 최신 보안 업데이트와 패치를 적용해야 한다. 이러한 패치 작업을 주기적이고 체계적으로 수행함으로써, Microservice의 보안성과 안정성을 확보할 수 있다. |
4.3 Orchestration 도구로 배포와 업데이트를 자동화
| Orchestration 서비스를 사용하여 배포와 업데이트가 자동화되어야 한다. 오케스트레이션 서비스는 여러 서비스나 애플리케이션의 자동 배포와 관리를 도와주는 도구이므로 이를 통해 일관성 있는 배포, 빠른 시장 반응, 오류 감소와 같은 이점을 얻을 수 있으며 자동화된 배포는 수동 작업에서 발생할 수 있는 사람으로 인한 오류를 줄이고, 배포 시간을 단축시키며, 시스템의 안정성을 향상시킬 수 있다. |
4.4 인증자격증명 등 모든 네트워크 트래픽은 TLS로 송수신 암호화
| Microservice Architecture내 Endpoint간 인증자격증명을 포함한 모든 네트워크 트래픽은 TLS를 사용하여 송수신데이터의 보안성을 확보해야 한다. 인증 자격증명과 같이 민감한 정보가 포함된 트래픽은 특히 중요하므로, 이를 보호하기 위해 TLS를 사용하는 것은 필수이다. |
5. 데이터 및 메시징 권한 제한
5.1 불필요한 API 호출 최소화 정책수립 적용
| API 호출은 해당 사용자나 시스템의 기능 수행에 필요한 것만으로 제한하여 불필요한 API 호출을 최소화해야 한다. 사용자나 시스템이 필요 이상의 API에 접근할 수 있다면, 이것은 잠재적인 보안 위협이 될 수 있기 때문에 특정 기능 수행을 위해 필요한 API만 호출하도록 제한함으로써, API의 남용을 방지하고 보안성을 강화할 수 있다. |
5.2 불필요한 데이터 접근 최소화 정책수립 적용
| 최소 권한 원칙에 따라 해당 서비스의 기능 수행에 필요한 최소한의 데이터로 사용 가능한 데이터를 제한해야 한다. 서비스에 필요 이상의 데이터 접근 권한을 부여하면, 잠재적인 보안 위험 요소가 될 수 있다. 특정 서비스의 기능을 수행하기 위해 반드시 필요한 데이터만을 제공함으로써, 데이터 유출 또는 무단 접근의 위험을 최소화하고, 서비스의 보안성을 향상시킬 수 있다. |
5.3 데이터베이스 자격증명은 최소한의 데이터만으로 접근통제 적용
| 데이터베이스 자격증명은 해당 자격증명이 발급된 기능을 수행하기 위해 필요한 최소한의 데이터에만 접근할 수 있어야 한다. 자격증명이 과도한 접근 권한을 가질 경우, 그 자격증명이 노출되면 데이터베이스 내의 많은 정보가 위험에 처할 수 있다. 따라서 자격증명은 해당 자격증명으로 수행해야 할 특정 기능과 관련된 데이터에만 접근할 수 있도록 제한되어야 하며 이렇게 함으로써, 만약 자격증명이 무단으로 노출되더라도, 노출되는 데이터의 양을 최소화할 수 있다. |
5.4 데이터베이스 자격증명은 최소한의 필요기능으로 접근통제 적용
| 데이터베이스의 기능과 작업에 대한 접근을 제한하기 위하여 데이터베이스 자격증명은 해당 자격증명이 발급된 기능을 수행하는 데 필요한 기능과 작업에만 접근할 수 있어야 한다. 각 자격증명에 부여된 권한은 해당 자격증명의 목적에만 맞게 제한되어야 한다. 예를 들어, 특정 데이터를 읽기만 해야 하는 기능에 대한 자격증명은 데이터를 수정하거나 삭제하는 권한을 가져서는 안된다. 이러한 제한을 통해 잘못된 사용 또는 무단 사용으로 인한 위험을 최소화할 수 있다. |
5.5 메시징 채널을 최소한으로 접근통제 적용
| 메시징 채널에 대한 접근을 제한하기 위하여 서비스는 그들의 기능 수행을 위해 필요한 메시징 채널에만 접근할 수 있도록 구현해야 한다. 서비스가 그 기능과 무관한 메시징 채널에 접근할 수 있게 되면, 잘못된 메시지 전송 또는 민감한 정보의 무단 접근 같은 보안 위협 요소가 될 수 있다. 따라서, 서비스는 해당 서비스의 목적과 관련된 메시징 채널에만 접근할 수 있도록 제한되어야 한다. |
5.6 메시징 채널 접근권한 세분화 및 최소한으로 적용
| 메시징 채널에 대한 접근 권한을 세분화하기 위하여 부여된 메시징 채널에 대한 접근은 Read only, Write 등과 같이 필요한 기능으로 제한되어야 한다. 예를 들어, 어떤 서비스가 메시지를 읽기만 해야 한다면, 해당 채널에 쓰기 권한을 부여해서는 안 된다. 이렇게 각 기능에 맞게 접근 권한을 세분화하면, 잘못된 작업이나 무단 작업으로 인한 위험을 줄일 수 있다. |
5.6 메시징 자격증명의 저장 및 송수신에 보호조치 적용
| 메시징의 자격증명은 저장 중이든 전송 중이든 적절한 보호조치가 적용되어야 한다. 저장 또는 전송 중인 메시징 자격증명은 공격자에게 노출될 경우 피해가 크기 때문에 암호화와 같은 방법을 사용하여 적절하게 보호되어야 한다. |
6. 모니터링 및 로깅 관련 요구사항
6.1 모든 Microservice에 대한 로그 생성
| Microservice와 관련된 모든 활동의 투명성과 추적성을 보장하기 위하여 개별 Microservice와 Microservice Gateway는 조직내 보안정책에 따라 적절한 로그를 생성해야 한다. 로그는 시스템 내의 모든 활동을 기록하며, 보안 문제나 시스템 오류를 조사할 때 중요한 정보를 제공하기 때문에 로그를 생성하여 시스템의 안정성과 보안을 유지하도록 한다. |
6.2 중앙집중식 로깅 및 모니터링 시스템에 모든 API요청 저장
| 모든 API 요청은 중앙집중식 로깅 및 모니터링 시스템에 기록되어야 한다. 이를 통해 보안 위반, 시스템 오류, 불법 접근 등의 사건을 빠르게 탐지하고 대응할 수 있다. |
6.3 Microservice의 성능 및 처리량 지표 로깅, 정상지표 설정
| Microservice의 성능 모니터링과 최적화를 위하여 성능 및 처리량 지표를 로깅해야 하며 정상지표에 대한 기본세트를 설정해야 한다. 성능 및 처리량 지표는 서비스의 작동 상태와 효율성을 평가하는 데 중요한 정보를 제공한다. 정상적인 지표의 기본 세트를 설정함으로써, 시스템의 변동이나 이상 행동을 쉽게 감지하고 대응할 수 있다. 예를 들어, 지표가 급격하게 변동할 경우, 이는 시스템에 문제가 있을 수 있음을 나타낼 수 있으므로 즉각적인 조치가 필요하다. |
6.4 비정상활동에 대한 지표설정 및 알람 임계값 설정
| 로그 및 모니터링 시스템은 시스템의 비정상적인 활동을 신속하게 탐지하고 대응하기 위하여 비정상적인 지표에 대한 알림을 발생시키는 임계값이 설정되어야 한다. 예를 들어, 서비스의 처리량이 평소보다 급격하게 떨어진다면, 이는 서비스에 문제가 있을 수 있음을 나타낼 수 있으며 이런 경우, 로깅 및 모니터링 시스템은 해당 임계값에 도달했을 때 즉각적으로 관리자나 담당자에게 알림을 보내어 조사를 촉구할 수 있다. |
