어플리케이션 보안

애플리케이션 보안

애플리케이션을 클라우드 플랫폼 호스트시 이점

• 클라우드 공유 책임 모델 : 클라우드 공급자의 제어 하에서 물리적 네트워크, 빌딩 및 호스트 수준에서 보안을 이동함.

운영 보안 평가

• 애플리케이션 배포 후에도 계속해서 보안 상태 평가, 문제점 완화 방법 확인, 지식을 소프트웨어 개발 주기에 다시 제공해야 함.
• 조직에서 이 평가를 수행하는 깊이 : 데이터 개인 정보 보호 요구 사항, 소프트웨어 개발 및 운영 팀의 완성도 수준을 측정하는 요소
• 보안 취약성을 검사하는 소프트웨어 서비스를 사용 → 프로세스를 자동화하여 주기적으로 보안 문제를 평가할 수 있음. ⇒ 팀에 침투 테스트처럼 비용이 많이 드는 수동 프로세스를 수행해야 하는 부담을 지우지 않고 이러한 이점을 제공함.
• Azure Security Center
  • 현재 모든 Azure 구독에 대해 기본적으로 사용되는 무료 서비스,
  • Azure Application Gateway, Azure Web Application Firewall과 같은 다른 Azure 애플리케이션 수준 서비스와 긴밀하게 통합됨.
  • 해당 서비스의 로그를 분석하여 알려진 취약성을 실시간 보고, 취약성을 완화하기 위한 대응 방법을 추천할 수 있음.
  • 공격에 대응하여 자동으로 플레이북을 실행하도록 시큐리티 센터를 구성할 수도 있음.

경계로서의 ID

• ID유효성검사 : 애플리케이션에 대한 공격 방어하는 첫번째 방어선.
• 세션을 인증하고 권한을 부여하여 웹 애플리케이션 액세스를 제한→ 공격 노출 영역을 줄일 수 있음.
• Azure AD, Azure AD B2C→ ID 책임을 오프로드하고 완전 관리형 서비스에 액세스하는 효과적인 방법을 제공함.
  • Azure AD 조건부 액세스 정책, Privileged Identity Management 및 ID 보호 컨트롤은 무단 액세스를 방지하고 변경 내용을 감사할 수 있도록 도움.

데이터 보호

• 거의 모든 공격의 목표는 고객 데이터이다. ⇒ 애플리케이션, 데이터 스토리지 레이어 간에 데이터를 안전하게 저장하고 전송하는 것이 중요함.
• Azure Blob Storage에 저장된 데이터를 암호화 → 클라이언트 쪽 암호화를 사용하여 메모리의 데이터가 스토리지 서비스에 기록되기 전에 암호화할 수 있음. 암호화 지원하는 라이브러리 : .NET, Java 및 Python 에서 지원되며 데이터 암호화를 애플리케이션에 직접 통합하여 데이터 무결성 강화할 수 있음.

보안 키 및 비밀 스토리지

• 애플리케이션 비밀(연결 문자열, 암호 등) 및 암호화 키를 데이터 액세스에 사용되는 애플리케이션과 분리하는 것이 매우 중요
• 암호화 키 , 애플리케이션 비밀을 애플리케이션 코드, 구성 파일에 저장하면 절대 안됨.
• Azure Key Vault와 같은 안전한 저장소를 사용해야 함.
• Azure 리소스에 대한 관리 서비스 ID를 통한 애플리케이션 ID로 제한할 ㅅ 있음.
• 암호화 키 유출 시 노출을 제한하기 위해 키를 정기적으로 바꿀 수 있음.
• 온 프레미스 HSM 에서 생성한 자체 암호화 키를 사용할 수 있음. Azure Key Vault 인스턴스가 단일 테넌트의 개별 HSM으로 구현되는 것을 필수 요건으로 지정할 수도 있음.