01. 아키텍처 관점의 정보보안

엔터프라이즈 시스템의 요구사항중에서 보안에 대한 요구는 점점 강화될 것이다. 이전에는 개인 정보를 주로 다루는 금융이나 대형 쇼핑몰 사이트등 조금 좁은 업종을 대상으로 개인 정보 보안이 강조었지만, 그런 업종에서의 대형 개인 정보 유출 뿐만 아니라 원자력 발전소, 할인마트 등에서의 정보 유출 등이 계속 발생함으로써 이제는 법규를 통해서 보안을 강제할 단계가 된 것으로 본다. 

이렇게 법규로 정해지면 형평상 어떤 업종은 유예기간을 두고 할 수 있는 것이 아니다. 모든 기업의 정보 시스템은 법에서 요구하는 보안 사항을 지켜야 한다. 

보안과 관련된 요구사항은 여러가지가 있을 수 있다. 모의해킹에서 취약한 점이 발견되어서 코드의 보안을 강화하고, 암호화를 하고 접근제어를 하고 누가 언제 어떤 정보에 접근했는지 로그를 남기고 통신 레벨에서의 데이터 보안을 위해서 HTTPS를 사용하고 등등의 작업들을 해야 한다고 상상해 보자. 

이런 작업을 어떻게 정보 시스템에 적용할까? 보안의 요구사항을 적용하는 방법도 다른 요구사항을 적용하는 방법과 유사하게 2가지가 있을 수 있을 것 같다. 

	사안별 해결	보안 로드맵 기반
	사안별로 요구사항이 발생할때마다 하나씩 적용하는 방법	보안 관점에서 필요한 요구사항을 모두 벌려놓고 이 요구사항들과 정보 시스템간의 연관성과 영향도를 전체적으로 고려해본다.  이때 다른 조직과 단체에서 제공하고 있는 보안 레퍼런스도 참조한다.  그래서 보안 관점에서 현재의 모습과 궁극으로 가야할 TO-BE 모습간의 갭(gap)을 도출해내서 그 갭을 보완해나가는 방법으로 보안 요구사항을 적용하는 방법.
장점	요구사항에 빠른 시간안에 요구사항에 대응할 수 이어서, 애자일 방법론과 유사하게 시간적인 효과를 볼 수 있다. 수 있다. 코딩 패턴에서 사용되는 "리팩토링"같은 기법을 사용해서 아키텍처에서도 공통 내용을 추상화함으로써 "보안 로드맵 기반"의 방법론과 유사한 요과를 볼 수 있다.	가장 큰 장점은 중복 작업이 줄어들 수 있다. 일단 완료된 작업을 뒤에 오는 다른 작업때문에 수정할 가능성이 작아진다.  또한 공통적인 기능을 하는 모듈을 반복해서 구현할 필요가 없다.  궁극적인 모습을 그려놓음으써 전체적인 작업 순서 및 일정을 우선순위에 따라서 적용할 수 있다.  또는 담당 인력이 바뀌더라도 정책과 전략은 남아 있다. 그래서 일관된 정책아래 작업이 지속될 수 있다.
단점	각 요구사항의 범위안에서만 영향도를 고려한다. 리팩토링을 통해서 반복 제거와 추상화라는 목표를 부분 달성할 수 있겠지만, 궁극적으로 추구하는 "TO-BE' 모습을 정의하지 않아 목표가 없는 방법론일 수 있다.  그리고 고객은 "사안별 해결"을 했으면 끝이지, "리팩토링"에 해한 필요성은 느끼지 못한다.  결국, 엔터프라이즈 시스템은 소위 누더기(?)로 변할 가능성 있음.	보안의 전체적인 관점에 현재의 정보 시스템의 모습을 파악해야 하는 관계로 시간이 소요될 수 있다.

소프트웨어 관점에서의 시스템을 어떤 아키텍처로 만들든지 예를 들어 Client-server로 만들던지 레이어 스타일로 만들던지 그리고 통신을 HTTP로 하던지 TCP, 파이프 라인으로 하던지 호출 방식을 동기로 하든지 비동기로 하던지 등등 어떤 소프트웨어 아키텍처로 하든지 보안에 대한 요구사항은 이와 별도로 추상화된 레벨에서 정의해서 각자의 보안 프레임워크로 간직해 둘 수 있다. 그래서 새로운 보안 요구 사항이 들어올때 그 프레임워크에 맞게 적용해야 한다. 그 프레임워크에서 커버할 수 없는 경우에는 프레임워크 자체의 업데이트도 있을 수 있을 것이다.  

기업이 보안에 신경을 안쓰다보니까 법에서 미주알 고주알 참견을 하는 상황까지 되었지만, 법은 사용자 입장에서 요구사항만 내 놓을 뿐이다. 요구사항에 대한 자신만의 큰 그림은 기업에서 직접 그려야 한다. 

이제 정보 보안이라는 관점에서 큰 그림을 그려보자.