웹 애플리케이션 보안: 정찰, 공격, 방어 세 단계로 배우는 웹 애플리케이션 보안의 모든 것

264

3

부

방어

18.5

마치며

18

장에서 논의한 것과 같이 애플리케이션을 구축할 때 고려해야 할 사항이 많이 있다. 개발 조

직에서 새로운 애플리케이션을 개발할 때마다 숙련된 보안 엔지니어나 아키텍트가 애플리케이

션 설계와 아키텍처를 주의 깊게 분석해야 한다. 부적절한 인증 스킴이라든지 검색 엔진과의

미숙한 통합 같은 깊은 보안 결함은 애플리케이션을 위험에 빠뜨리며 해결하기가 쉽지 않다.

고객이 여러분의 애플리케이션에 의존해 업무를 하기 시작하면 특히 계약서를 작성해 서명한

뒤에는 아키텍처 수준의 보안 버그를 해결하는 것은 골칫거리가 된다.

18

장의 시작에서 아키텍처 단계에서 보안 결함을 수정하는 비용이 제품에서 찾는 것에 비해

30

~

60

배 적게 든다는

NIST

의 추정치를 언급했다.

이러한 수치가 나오는 것은 다음과 같은 사실이 복합적으로 작용하기 때문일 것이다.

●

고객이 안전하지 않은 기능에 의존하고 있을 수 있으므로 안전한 기능을 구축하고 다운

타임이 발생하지 않도록 완화 계획과 함께 제공해야 한다.

●

깊은 아키텍처 수준 보안 결함을 해결하려면 안전하지 않은 모듈 외에도 상당수의 모듈

을 재작성해야 할 수 있다. 복잡한

3D

비디오 게임을 예로 들면 멀티플레이어 모듈에 결

함이 있는 경우 네트워킹 모듈만 재작성하는 것이 아니라 그것에 의존하는 게임 모듈까지

재작성해야 할 수 있다. 보안성을 높이기 위해 기반 기술을 교체해야 하는 경우 (예를 들

어

UDP

나

TCP

네트워킹을 교체하는 경우 )에 특히 그렇다.

●

보안 결함이 이미 익스플로잇된 ...