전통적인 web-db 구조 대신 web-was(api)-db 구조로 운영하는 것은 여러 보안 이점이 있습니다. 이러한 아키텍처는 분리된 레이어를 통해 보안을 강화하며, 각 레이어가 서로 다른 보안 요구 사항과 위험을 관리할 수 있도록 합니다. 특히 API를 사용하는 경우, 보안 위험을 줄이고 보안 설정의 정확성을 높일 수 있습니다.
- 관리의 용이성: WEB/WAS 구조에서는 웹 서버와 WAS가 분리되어 있어 서버 관리 및 장애 대응이 더욱 용이합니다. 웹 서버와 WAS의 역할이 구분되어 있기 때문에 관리 및 유지보수가 더 쉽고, 장애 발생 시 대처 방안도 명확해집니다.
- 안정성 및 가용성: 이중화를 통해 안정성을 높일 수 있습니다. 웹 서버와 WAS가 분리되어 있으면, 하나의 시스템에 문제가 발생해도 다른 시스템은 계속 작동할 수 있습니다. 또한, 요청이 급증하거나 돌발적인 시스템 장애가 발생할 때 이러한 구조는 더 높은 가용성과 확장성을 제공합니다.
- API 보안 강화: API 보안은 웹 애플리케이션 보안의 중요한 부분입니다. OWASP에 따르면, API 보안에는 취약한 인증, 보안 설정 오류, 부적절한 자산 관리 등의 위험이 포함됩니다. 이러한 위험을 관리하고 최소화하기 위해서는 웹 서버와 API 서버(WAS)를 분리하는 것이 중요합니다.
- 웹 애플리케이션 보안 전략: 웹 애플리케이션 보안 전략에는 DDoS 완화, WAF(웹 애플리케이션 방화벽) 구현, 데이터 암호화, 정기적인 취약점 스캔 및 패치 적용 등이 포함됩니다. 이러한 전략들은 웹 애플리케이션의 전체 보안 포스터를 강화하는데 기여하며, web-was(api)-db 구조는 이러한 전략들을 구현하기에 더욱 적합한 환경을 제공합니다.
종합적으로 볼 때, web-was(api)-db 아키텍처는 웹 애플리케이션의 보안을 강화하는 데 중요한 역할을 합니다. 이 구조는 관리의 용이성, 안정성 및 가용성, API 보안, 그리고 웹 애플리케이션 보안 전략을 개선하는 데 도움이 됩니다. 따라서 보안 관점에서 이 구조를 운영하는 것이 매우 권장됩니다.
API 호출 시 토큰을 안전하게 전달하기 위한 방법에는 여러 가지가 있으며, 보안 기준을 설정할 때 이를 고려해야 합니다. 여기에는 다음과 같은 요소들이 포함됩니다.
- HTTPS 프로토콜 사용: API 호출 시 토큰을 전송할 때는 반드시 HTTPS 프로토콜을 사용해야 합니다. HTTPS는 전송 중인 데이터를 암호화하여 중간에서 패킷을 가로채더라도 데이터가 노출되지 않도록 보호합니다.
- Digest Access Authentication: HTTP Basic Auth의 단점을 개선한 방식으로, 클라이언트와 서버 간에 공유되는 난수값(nonce)을 사용하여 사용자 ID와 비밀번호를 해시화하여 전송합니다. 이 방식은 평문 형태로 데이터가 전송되지 않기 때문에 기본 인증보다 보안성이 높습니다.
- 클라이언트 인증 추가: 사용자 인증뿐만 아니라 클라이언트 인증도 추가하는 것이 좋습니다. 예를 들어, 페이스북은 API 토큰 발급 시 사용자 ID, 비밀번호와 함께 클라이언트 ID와 클라이언트 Secret도 요구합니다.
- IP 화이트리스트: 특정 IP 주소에서만 API 호출이 가능하도록 설정하는 것도 한 방법입니다. 이를 통해 무단 접근을 제한할 수 있습니다.
- API 엔드포인트 추적 및 인증: 모든 API 엔드포인트를 추적하고, 인증을 통해 호출이 합법적인 클라이언트로부터 오는지 확인하는 것이 중요합니다. 상호 TLS와 같은 공개 키 암호화 방식을 사용하여 서로를 검증하는 인증 방법이 효과적입니다.
- API 스키마 유효성 검사: API 스키마 유효성 검사를 통해 잘못된 API 호출을 식별하고 차단하는 것도 중요합니다. 이는 API를 악용하려는 시도를 차단하는 데 도움이 됩니다.
- DDoS 완화 사용: 과도한 요청을 차단하거나 흡수하여 서버에 과부하가 걸리지 않도록 DDoS 완화 서비스를 사용하는 것도 하나의 방법입니다.
위의 방법들은 API 호출 시 토큰을 보다 안전하게 전달하고 API 보안을 강화하는 데 도움이 될 것입니다. POST 메서드를 사용하는 것도 좋지만, 위에 언급된 방법들과 결합하여 사용하는 것이 더욱 효과적인 보안을 제공할 수 있습니다.
API 호출 시 인증 토큰을 전달하는 방법에 대한 보안 기준을 정의할 때 고려해야 할 주요 요소들은 다음과 같습니다.
- 전송 방식: 인증 토큰은 주로 HTTP 헤더를 통해 전송되어야 합니다. 이 방법은 로깅이나 캐싱에서 토큰이 노출되는 것을 방지하고, 보안적으로 표준화된 접근 방법을 제공합니다.
- HTTPS 사용: 모든 API 통신은 HTTPS를 통해 이루어져야 합니다. HTTPS는 데이터를 암호화하여 중간자 공격으로부터 보호합니다.
- HTTP 메서드: 일반적으로 GET 메서드는 URL의 쿼리 스트링에 데이터를 포함시키기 때문에 인증 토큰을 전달하기에 적합하지 않습니다. POST나 다른 HTTP 메서드를 사용하여 토큰을 전달하는 것이 좋습니다.
- 인증 방식: 기본 인증(Basic Auth), 디제스트 인증(Digest Auth), OAuth 등 다양한 인증 방식 중에서 적절한 것을 선택해야 합니다. 보안 수준과 API 사용 환경에 따라 선택할 수 있는 인증 방식이 달라집니다.
- 토큰의 보안: 토큰 자체도 보안적으로 안전해야 합니다. 예를 들어, JWT(JSON Web Token)와 같은 자체적으로 보안이 강화된 토큰을 사용할 수 있습니다.
- 접근 제한: 필요한 경우, 특정 IP 주소에서만 API 호출이 가능하도록 설정하여 무단 접근을 제한하는 것도 고려해 볼 수 있습니다.
- 로깅 및 모니터링: 인증 토큰을 포함한 API 호출에 대한 로깅과 모니터링을 실시하여 보안 문제를 조기에 탐지하고 대응할 수 있어야 합니다.
이러한 기준들을 바탕으로 API 호출 시 인증 토큰의 전달 방법을 정의하고, API의 보안을 강화할 수 있습니다. 기본적으로는 헤더를 통한 전송이 권장되지만, POST 방식을 사용하는 것도 특정 상황에서는 적절할 수 있습니다. 중요한 것은 전송되는 토큰이 로그나 캐시에 남지 않도록 하는 것입니다.
각 핵심 보안 아이템에 대해 실무적으로 담당자가 취할 수 있는 구체적인 조치들을 포함합니다.
- Dev/QA 환경의 보안 강화
- 환경 구성 검토: 개발 및 QA 환경이 생산 환경과 격리되어 있는지 확인하고, 필요한 경우 추가적인 분리 조치를 취합니다.
- 보안 정책 적용: 생산 환경에서 사용되는 보안 정책과 동일한 수준의 보안 정책을 Dev/QA 환경에 적용합니다.
- 접근 권한 감사: 누가 Dev/QA 환경에 접근할 수 있는지 검토하고, 필요 이상의 접근 권한을 가진 사용자가 없는지 확인합니다.
- 다중 인증 요소(MFA)의 필수적 적용
- MFA 활성화: 모든 사용자 계정에 대해 MFA를 활성화합니다. 이미 활성화된 경우, 설정을 검토하여 적절한지 확인합니다.
- 사용자 교육: 모든 사용자에게 MFA의 중요성을 교육하고, MFA 사용 방법에 대해 안내합니다.
- Application 권한의 관리
- 권한 검토 및 조정: 해당 목록을 검토하여 불필요한 권한이 부여된 계정을 식별하고, 필요한 경우 권한을 조정하거나 제거합니다.
- OAuth 애플리케이션의 관리
- OAuth 애플리케이션 목록 검토: 조직 내에서 사용 중인 모든 OAuth 애플리케이션을 나열하고 검토합니다.
- 권한 및 활동 감사: 각 애플리케이션의 권한 수준을 확인하고, 이상 활동이 없는지 모니터링합니다.
- 감사 및 모니터링 시스템의 강화
- 보안 로그 설정 검토: 현재 보안 로그 및 감사 시스템의 설정을 검토하고, 필요한 경우 추가적인 로깅 기능을 활성화합니다.
- 위협 인텔리전스 연동: 보안 시스템이 최신 위협 인텔리전스와 연동되어 있는지 확인하고, 누락된 연동이 있다면 추가합니다.
각 항목별로 필요한 담당자가 존재하지 않는 경우, IT 관리 팀, 네트워크 관리 팀, 또는 보안 팀과 협력하여 이러한 조치들을 시행할 수 있습니다. 중요한 것은 각 단계가 체계적으로 실행되고 지속적으로 관리되어야 한다는 점입니다.
댓글