일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- stride
- gameplay tag
- 게임개발
- 언리얼엔진
- ability task
- os
- Aegis
- attribute
- 언리얼 엔진
- listen server
- photon fusion2
- widget
- 보안
- gas
- MAC
- Unreal Engine
- Replication
- animation
- 게임 개발
- Multiplay
- C++
- UI
- rpc
- unity
- local prediction
- 유니티
- CTF
- level design
- gameplay ability system
- gameplay effect
- Today
- Total
Replicated
보안 위협 완화 전략 본문
안전한 시스템 / 소프트웨어 개발을 위한 고려사항
소프트웨어 설계 및 구현 관점
- 보안 기능 설계
- 입력 데이터 검증
- 세션 관리
- 시큐어 코딩
소프트웨어 아키텍처 관점
- 안전한 소프트웨어 아키텍처 설계에 중점
- 공격 표면 최소화
- 데이터 노출 최소화, 인증 및 접근 정책 강화
시스템 아키텍처 관점
- 보안 강화 아키텍처 도입 .. ZTA
위협 완화
- 문제의 심각성, 범위, 영향을 감소시키는 사전 대응
- 위험을 줄여주지만 제거하지는 못함
- 잠재적인 위협 요소를 파악하고 각 위협이 미칠 수 있는 영향도 분석
- 화재 경보, 안전벨트, 에어백, 속도 제한, 안전 관리 규정 등..
소프트웨어 보안 위협 완화
- 소프트웨어 보안 위협 완화는 개발 전 과정에 걸쳐 수행
- 위협 모델링을 취약점 식별은 중요하지만, 식별된 취약점을 항상 제거할 수는 없음
- 위험 평가를 통해 가장 큰 위협을 먼저 처리하고 최선을 다해 억제해야 함
- 설계 단계에서부터 보안을 고려하는 'Secure by Design' 원칙 적용
- 민감한 데이터 처리 -> 데이터 접근 최소화, 정보 수집 축소, 오래된 데이터 접근 삭제 등을 통해 위협 완화
- 위협 완화는 기회가 있을 때마다 줄여 나가는 것
위협 완화 방안
공격 표면 최소화
- 공격자가 시스템을 공격할 수 있는 진입점과 취약점을 체계적으로 식별하고 제거 또는 축소하는 보안 전략
- 시스템이 외부에 노출되는 모든 접점을 확인하여 최소화함으로써 공격자가 악용할 수 있는 기회를 근본적으로 줄이는 것이 목표
- 공격 표면 축소 검토: 각 진입점에 대한 코드 및 데이터의 영향도 관점에서 검토
- 동일 기능을 수행하는 여러 인터페이스 통합 검토
- 외부 접근 최소화, 인터페이스 최소화, 불필요하게 노출된 서비스 최소화 방안 등
공격 표면 최소화 효과
위험 감소
- 시스템이 외부에 노출되는 접점이 많을 수록 공격자가 취약점을 발견하고 악용할 수 있는 가능성이 높아짐
- 공격 표면을 최소함으로써 이러한 위험을 근본적으로 줄일 수 있음
리소스 최적화
- 모니터링 및 관리 포인트가 감소
- 리소스를 핵심적인 부분에 더욱 집중 투입 가능
복잡성 감소
- 시스템 복잡도가 낮아지면서 보안 취약점이 발생할 수 있는 가능성 감소
- 시스템 전반의 보안 상태를 더 효과적으로 파악하고 관리 가능
비용 효율성
- 취약점 관리 및 보안 패치 적용 지점이 감소
- 전반적인 보안 관리 비용 절감 가능
공격 표면 최소화 방법
- 불필요한 서비스와 기능 제거
- 필수적인 프로토콜 및 포트만 개방
- 네트워크 세그멘테이션 적용
- 중요 자산의 물리적, 논리적 분리
-> 클라이언트 / 서버 시스템에서 기능을 클라이언트로 이동시켜 서버의 공격 표면을 최소화하는 방법
-> 사용자 API 호출 필요 시 인증 후 API 호출이 가능하도록 구현
-> 배포 및 운영에 대한 인터페이스는 방화벽과 같은 보안 장비를 통해 서비스
-> 네트워크를 이용한 원격 관리 기능 등은 필요한 경우에만 활성화되도록 관리
SDP (Software Defined Perimeter)
네트워크 자원을 외부에서 볼 수 없게 숨기고 인증된 사용자만이 접근할 수 있도록 제공하는 제로 트러스트 기반의 보안 아키텍처
동적 접근 제어 제공
- 사용자 인증 후에만 리소스에 대한 일시적 접근 권한 부여
- 세션 종료 시 접근 경로도 함께 제거되어 공격 표면 최소화
Micro Segmentation
- 각 어플리케이션 및 서비스 격리
- 한 지점이 침해되어도 횡적 이동 격리
채널 분리
- Control Plane - Control Path
- Data Plane - Data Path
Narrow Vulnerability Window (좁은 취약점 창) 개요
- 총을 발사한 순간에만 안전 장치를 풀고 이후 바로 안전 장치를 잠그는 방식
- 서로 다른 신뢰 수준 간의 데이터나 제어 흐름이 교차하는 경계에서 발생할 수 있는 보안 취약점의 노출 시간을 최소화하는 전략
- Time-of-Check to Time-of-Use (TOCTOU)
- 자원 상태를 검사하는 시점과 사용 시점 사이의 간격을 악용
- 레이스 컨디션의 한 형태로 검사 시점과 사용 시점 사이에 자원의 상태가 변경될 수 있는 문제
Narrow Vulnerability Window 완화 방법
원자적 (atomic) 연산 처리
- 검사와 실행을 분리할 수 없는 단일 원자적 작업으로 구현
- 데이터 일관성을 보장하고 레이스 컨디션 취약점 예방
임시 권한 상승
- 필요한 최소 시간 동안만 높은 권한으로 작업 수행 후 즉시 권한 해제
- 권한 상승 및 해제 과정의 로깅 처리
동기화 메커니즘 활용
- 뮤텍스, 세마포어 등을 이용한 동시성 제어
- 임계 영역에 대한 배타적 접근 보장
- 데드락 방지를 위한 적절한 락 관리
고려사항
- 성능 영향: 원자적 연산 처리 및 동기화 메커니즘으로 인한 성능 저하
- 오류 처리: 예외 사항에 대한 명확한 처리 로직
- 모니터링: 취약점 관련 이벤트 로깅, 주기적인 보안 감소
데이터 노출 최소화
데이터 최소화 원칙 적용
- 필요한 최소한의 데이터만 수집 및 저장
- 사용 목적이 완료된 데이터 즉각적인 폐기
- 임시 데이터의 안전한 처리
데이터 보호 전략
- 저장 데이터 보호
- 전송 데이터 보호
- 메모리 상 데이터 보호
메모리 관리
- 민감 데이터 사용 후 즉시 메모리에서 제거
- 메모리 덤프 방지
- 안전한 메모리 할당 및 해제
인증 및 접근 제어 정책 강화
안전한 패스워드 정책
- 최소 길이 및 복잡도 요구사항 설정
- 일정 주기 패스워드 변경 및 이전 패스워드 재사용 금지
- 기본 패스워드 강제 변경 정책
로그인 시도 제한
- 일정 횟수 이상 실패 시 계정 잠금
- 비정상적인 로그인 시도 모니터링 및 알림
다중 인증 (MFA) 정책
- 지식 기반: 비밀 번호, PIN 번호 등 사용자가 알고 있는 정보
- 소유 기반: OTP 토큰, 보안 카드 등 사용자가 소유한 물건
- 생체 기반: 지문, 홍채, 얼굴 인식 등 사용자 생체 정보
- 중요 작업 수행 시 반드시 2차 인증 사용
- 둘 중 하나 뚫려도 하나 더 있으니까 보안성 상승
접근제어
- 역할 기반 접근 제어 (RBAC) 정책
- 최소 권한 원칙 적용
- 직무 분리 원칙 준수
- 리소스 (파일 시스템 / 데이터베이스 / 네트워크) 별 접근 제어
API 인증 및 접근 제어
- API 키 관리 및 주기적 갱신
- OAuth, JWT 등 표준 인증 프로토콜 사용
- API 요청 제한 및 모니터링
감사 및 모니터링
- 접근 제어 이벤트 로깅
- 비정상 접근 탐지 로깅
- 권한 변경 이력 관리
인터페이스
- 소프트웨어 설계는 시스템의 기능적 부분에 대응되는 컴포넌트들로 구성
- 각 컴포넌트는 인터페이스를 이용해 연결
- 인터페이스는 데이터와 제어 흐름을 나타냄
- 신뢰 경계 간 연결 인터페이스에 대한 보안 및 취약점 검토 필요
대규모 시스템에는 네트워크 간, 프로세스 간, 프로세스 내, 운영체제와 프로세스 간 등과 같은 다양한 인터페이스 존재
프로세스 간 통산 맟 네트워크 통신 인터페이스는 대표적인 위협 모델링 주요 관심사
소프트웨어 설계는 보안 위협을 줄이기 위해 민감한 정보 흐름을 제한하고 높은 권한의 접근 영역을 최소화하기 위한 컴포넌트 구조화가 필요
네트워크 통신 및 스토리지
- 네트워크 통신 보안 위협에 대한 고려
- 통신 데이터의 기밀성 및 무결성 보장 필요 (통신 보안 프로토콜)
- >스토리지에 저장된 데이터 보안 위협에 대한 고려 필요
-> 저장된 데이터의 기밀성 및 무결성 보장 필요
-> 데이터의 가용성 보장을 위해 백업 정책 등을 이용
-> 백업 정책은 전체 데이터 백업 또는 트랜잭션에 의한 증분 백업 등을 고려
'소프트웨어 보안개발방법론' 카테고리의 다른 글
소프트웨어 공급망 공격과 SBOM, CC 인증 (0) | 2025.06.12 |
---|---|
ZTA와 경계 기반 보안 모델 (0) | 2025.06.12 |
DevSecOps, 역할 별 보안 활동, Best Practices (0) | 2025.06.12 |
Seven Touchpoints, CLASP (0) | 2025.06.12 |
MS-SDL (0) | 2025.06.12 |