[218호 웹진: SW공학 동영상] Cyber Security Engineering for Software and Systems Assurance

Cyber Security Engineering for Software and Systems Assurance

참석자

Nancy R. Mead - SEI fellow and principal researcher in the CERT Division of the Software Engineering Institute

Carol Woody - Senior member of the technical staff and the technical manager of the Cybersecurity Engineering Team

요약

소프트웨어 및 시스템 보증을 위한 사이버 보안 공학

시스템을 계속 구축되어야 하고 우리가 원하는 모든 기능을 필요로 합니다. 그것은 싸야 하고 빠르게 바뀌지 않아야 합니다. 사람들을 대체할 수 있어야 하고 일을 빨리 끝낼 수 있어야 합니다. 여분의 노력과 추가 비용이 들기 때문에 보안 장비에 대한 여유가 없습니다.

우리가 쓰는 훌륭한 보안 주체는 인수 관리자입니다. 계약이나 상업용 소프트웨어 구매 등을 통해 제품을 개발할뿐만 아니라 사이버 보안에 대해서 고민합니다. 또 다른 보안 주체는 실제로 시스템에 사이버 보안을 구축할 책임이 있는 개발 관리자와 기술자입니다. 그들은 의사 결정권자입니다.

사이버 보안에 종사하는 사람들도 시스템을 개발하고 습득할 때 사이버 보안이 왜 그렇게 중요한지의 연관성을 이해하지 못합니다. 블로그 포스트에서 사이버 보안 공학을 지원하기 위해 7가지 원칙에 대해 이야기했지만 7가지 원칙은 일종의 체계를 구성하는 것입니다.

리스크 관리를 추진력으로 삼았기 때문에 책에 대한 요점이 매우 중요하다고 생각합니다. 아무도 보안을 위한 구입하지 않기 때문입니다. 리스크 유형의 제어나 구조가 필요하고 기술에 대한 설명이 있어야 합니다. 이 기술로 무엇을 하고 있는지, 데이터는 어디에 있는지, 얼마나 광범위하게 정보를 배포하고 있는지, 어떤 종류의 사람들이 그것으로 작업할 것인지 말입니다. 이 모든 것은 의사 결정의 일부가 됩니다. 웹에 게시 될 수도 있고 모든 인터페이스를 제어하지 않고 액세스 될 수도 있습니다.

몇 가지 중요한 점을 제기합니다. 체크리스트를 위한 컨트롤 목록을 제공한다는 것과 소프트웨어를 어디에서 공급하는지에 대한 공급망 문제입니다. 공급망이 어떻게 생겼는지에 대해 알 수가 없습니다.

소프트웨어를 만드는 방법을 살펴 보는 것은 계획된 주요 프로세스입니다. 그러나 이 과정에서 보안을 계획하는 곳은 없습니다. 라이프 사이클 전반에 걸쳐 통합되어 있지 않으면 따로 계획하기 어렵습니다. 누군가 서비스 거부를 만들었고 특정인이 조작할 수 없기 때문에 문제가 생깁니다. 처음에 이러한 것이 만들어질 때 고려해야 합니다.

보안을 처음에 고려하지 않은 경우 나중에 잘 통합되지 않을 가능성이 있습니다. 왜냐하면 보안에 대한 결정이 미리 없었기 때문입니다. 전체 시스템을 안전하게 할 수 없기 때문에 전체 시스템이 문제가 생길 수 있습니다. 보안을 위한 패치의 지속 비용이 엄청난데 그나마 패치 주기에 지칠 수 있고 패치가 다른 문제를 일으킬 수도 있습니다.

집중적으로 고민해야 하는 방법 중 하나는 직원과 조직이 사이버 보안 역량을 향상시키는 방법입니다. 그렇지 않으면 보안 담당은 할 일이 너무 많은데 직원과 조직이 무엇을 해야할지 몰라 아무 것도 하지 않게 됩니다. 역량을 향상시켜 작은 증분 단계를 시작할 수 있으면 개선이 쉬워집니다. 사람들이 할 수 있는 가장 효과적인 방법입니다. 그런데 직원과 조직의 압박은 많습니다. 할 일이 너무 많다라고 생각할 텐데 성장이 필요합니다.

이 팟 캐스트는 SEI 웹 사이트 sei.cmu.edu/podcasts 및 Carnegie Mellon University의 iTunes U 사이트에서 제공됩니다. 항상 그렇듯이 질문이 있으시면 info@sei.cmu.edu로 전자 메일을 보내주십시오. 고맙습니다.

[218호 웹진: 인사이드이슈] 소프트웨어공학의 오해와 필요성

소프트웨어공학의 오해와 필요성

불과 얼마 전까지만 해도 소프트웨어 개발 프로세스나 개발 방법론 등은 개발자들에게 환영 받지 못할 정도로 소프트웨어를 개발할 때 필요한 요소들이 정리된 소프트웨어공학의 관심은 일부 전공자들에게 한정되어 있었다. 하지만 최근에 소프트웨어공학을 다시 살펴보자는 주장들이 많이 나오고 있어 호윤시스템 김기향 팀장과 소프트웨어공학을 전공한 윤광렬 박사를 만나 이야기를 나눠본다.

Q: 안녕하세요. 2000년 전후로 집중적인 관심을 받다가 그 이후 지속적으로 관심이 줄어들고 있던 소프트웨어공학이 요새 다시 회자되고 있습니다.

이 얘기를 들으시는 분 중에 요새 소프트웨어공학이 다시 얘기되는 것을 모르겠다는 분들도 많을 겁니다. 그런데 최근에 이슈가 많이 되고 있는 애자일(Agile)이나 마이크로 서비스(Micro Service), 클라우드 서비스(Cloud Service) 등 많은 부분이 소프트웨어공학 없이는 구현되기가 어려운 것들입니다. 녹아 들어있는 소프트웨어공학을 인지 못하시는 것뿐입니다.

<그림1> 소프트웨어공학 활용의 예

출처: http://blog.creation.net/306

최근까지도 소프트웨어공학을 소프트웨어를 개발하고 유지보수하는 생명주기 전반을 나타낸다고 이해하시는 분들이 많습니다. 특히 위키백과와 같은 사전적 정의도 이렇게 정의된 경우가 대부분이죠. 위키백과에서는 “소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다; 즉, 공학을 소프트웨어에 적용하는 것이다”라고 정의되어 있습니다. 물론 틀린 말은 아니지만 소프트웨어공학이 적용되는 범위는 훨씬 광범위하다는 것이죠.

“소프트웨어를 만들 때”라는 말을 하나의 시스템을 개발하는 것에만 국한하지 말고 어떠한 제품을 만들 때 소프트웨어를 어떻게 하면 잘 적용할 수 있는가 하는 것도 포함시켜야 합니다.

Q: “제품을 만들 때”라는 말이 이해가 어려운데 조금 자세히 말씀해주시겠습니까?

일반적으로 소프트웨어를 만든다고 하면 시스템을 설계해서 코딩을 하고 운영을 하게 됩니다. 말 그대로 소프트웨어가 단독으로 만들어지는 것이지요. SI가 이러한 형태로 개발이 되고 솔루션 개발에서도 이러한 방식을 취하는 경우가 많습니다. 그런데 소프트웨어가 다른 제품에 들어가는 경우도 많지 않습니까? 최근에는 자동차나 비행기, 공장 등지에서도 사용되고 있는 것이 현실이지요. 반도체는 컴퓨터에만 쓰이는 것으로 잘 알려져 있지만 사람이 사용하는 거의 모든 전자 제품에 들어가는 것처럼 소프트웨어도 비슷합니다.

<그림2> 임베디드 소프트웨어 활용의 예

출처: http://j.mp/ZYZ4KF

그림2에서처럼 임베디드 소프트웨어만 그런 것은 아닙니다. 이제 소프트웨어가 거의 모든 기계나 제품에 대부분 들어간다는 것을 인식해야 하고 이에 대비한 소프트웨어 만드는 방식을 준비해야 하는 것이죠.

Q: 요새 나오는 전자 제품에는 소프트웨어가 꼭 들어가니 소프트웨어를 적용하기 위해 소프트웨어공학이 필요하다는 말로 이해가 되네요. 맞나요?

맞는 말이긴 하지만 전자 제품이 아니더라도 소프트웨어공학은 소프트웨어를 만드는 방법적인 것을 말하는 것이기 때문에 개발 프로세스나 개발 방법론에 너무 한정해서는 안된다는 것을 말씀드리는 것입니다.

SI에서 소프트웨어를 만드는 것과 자동차에 들어가는 소프트웨어를 개발하는 것은 매우 다른 방법으로 소프트웨어가 이해되어야 하지만 소프트웨어를 만들기 위해 고민해야 하는 근본적인 문제는 똑같다는 것이죠. 예를 들면 소프트웨어가 어떤 운영체제에서 구동되는지, 보안상 필요한 부분은 무엇인지, 데이터는 어떻게 주고 받아야 하는지 등을 말합니다.

<그림3> 자동차에 탑재되는 소프트웨어의 예

출처: IT조선

그림3에서 차간거리제어를 보죠. 차간 거리를 제어하기 위해서는 거리를 측정하는 센서도 필요하지만 센서에서 거리를 읽어 판단하고 제어하는 소프트웨어도 필요할 겁니다. 이 때 만들어지는 소프트웨어를 SI 개발하듯이 개발할 수 있을까요? 아닐 겁니다. 이러한 소프트웨어를 만들 때는 또다른 방법이 필요하고 이러한 방법은 소프트웨어공학을 기반으로 정의되어야 한다는 것이 오늘 이야기의 핵심입니다.

Q: 그러한 소프트웨어 개발은 임베디드 소프트웨어에만 한정되어 있는 것 아닌가요? 그리고 임베디드 소프트웨어는 SI 개발과는 비교도 안될 만큼 개발 규모가 작지 않나요?

이 부분이 혼동하기 쉬운 부분입니다. 임베디드 소프트웨어는 이미 구분되어 있는 소프트웨어의 한 분야는 맞습니다. 하지만 어디서부터 어디까지 임베디드 소프트웨어라고 할 것인가라는 정의는 따로 없습니다. 어떤 제품이 원활하게 동작할 수 있도록 도와주는 것 정도로만 알고있는 것이 현실인데 최근에는 제품에 들어가는 소프트웨어가 임베디드 소프트웨어인지 시스템이라고 불릴 수 있는 소프트웨어인지 구분하기가 매우 애매해 졌다는 것입니다.

<그림4> 스마트 공장의 소프트웨어 활용

출처: http://www.iuchem.com

Q: 이전의 인터뷰에서 소프트웨어 산업이라는 말이 없어지고 모든 산업에서 소프트웨어가 부자재로 사용될 것이다라는 말이 기억납니다.

네 맞습니다. 소프트웨어 시스템이라고 불리던 SI 형태 위주였던 대규모 소프트웨어 산업에서 모든 산업에서 필요로 하는 소규모지만 반드시 필요한 맞춤형 소프트웨어로 바뀌고 있는 것이지요.

Q: 4차 산업혁명과 맥을 같이 하는 것으로 봐도 되겠네요. 그렇다면 소프트웨어공학과 연관해서 정리를 해주시죠.

4차 산업혁명은 인공지능 중심으로 산업이 변화되는 경우가 많은 것으로 알려져 있지요. 하지만 그 전에 모든 산업에서 필요한 소프트웨어를 탑재하게 됩니다. 초연결 사회를 지향하는 4차 산업혁명의 경우 소프트웨어를 더 효율적이고 체계적으로 적용하기 위해서는 반드시 소프트웨어공학이 필요합니다. 그림5는 고건 교수가 말하는 초연결 사회에서는 소프트웨어공학이 해답이라고 말한 것을 나타내고 있습니다. 물론 시각의 차이는 있겠지만 시대가 지날수록 소프트웨어를 만들 때 소프트웨어공학의 필요성은 점점 증가한다는 것이지요.

<그림5> 초연결 사회와 소프트웨어공학의 연관성

출처: 고건 - 22nd SW Quality Insight Conference

Q: 각 산업 군에서 소프트웨어가 필요하고 소프트웨어 개발을 위해 소프트웨어공학이 필요하다는 것은 이해가 갑니다. 그런데 소프트웨어공학을 어떻게 적용해야 하는 걸까요?

앞에서 소프트웨어공학은 개발 프로세스나 개발 방법론에 국한해서는 안된다는 말을 했습니다. 말하자면 소프트웨어를 만들 때 표준화된 프로세스와 방법론에 따라 만드는 것에서 벗어나야 한다는 것이죠. 각 산업 군에서 사용되는 소프트웨어는 각자 만들어지는 방식도 매우 다를 겁니다. 아니 다르게 만들어져야 합니다. 왜냐하면 각 산업 환경은 매우 다르기 때문에 거기에 맞는 소프트웨어가 있고 개발 방법도 정해진다는 말입니다.

기존에는 임베디드 소프트웨어라는 범위로 획일화된 개발 방식이 있었습니다. 하지만 지금은 자동차에서 사용되는 소프트웨어에서 고민해야 하는 것과 공장 자동화에서 사용되는 소프트웨어에서 고민해야 하는 것이 다를 수 있다는 것이죠. 여기서 말하는 다르다고 하는 것은 소프트웨어를 만드는 방법뿐만 아니라 운영체제, 보안, 데이터 전달, 더 나아가서는 인공지능으로 확대되는 것까지 다양한 형태가 존재합니다.

Q: 운영체제나 보안 같은 분야는 소프트웨어 개발에서 기본적으로 고민되는 부분 아닌가요? 각 산업에서 다르게 적용될 것이라는 이유는 무엇인가요?

예를 들면 자동차에서 고민해야 하는 보안 문제는 무엇일까요? 자율 주행을 적용했는데 해킹을 당해 도로 위에서 사고를 유발할 수 있다는 것을 고려해야 하고 스마트 공장에서 보안을 생각해야 한다면 IoT 장비에 장애가 일어나서 기계들을 멈추게 할 수 있죠. 이와 같이 보안 문제도 산업마다 다르게 나타나고 그에 대비한 소프트웨어 관점의 고민도 달라진다는 것입니다. 바로 산업 안전성 문제가 대두되는 것이죠.

<그림6> 소프트웨어 안정성 분석

산업에 적용해야 할 제품을 체계적으로 분석하고 특성에 맞게 설계하고 효율적인 개발을 통해 산업 발전에 도움을 줄 수 있는 소프트웨어를 만들기 위해서 소프트웨어공학은 이전보다 더 필요한 시대가 왔다고 봐야 합니다. 소프트웨어공학은 소프트웨어를 만드는 순서를 나타낸 것이 아니라 효율적인 소프트웨어를 체계적으로 개발하기 위한 것이 목적이기 때문입니다. 특히 4차 산업혁명이 나타난 지금 시점에 소프트웨어공학의 필요성은 계속 증가할 것으로 예상됩니다.

Q: 최근에 각 산업에서는 안전성에 대한 이슈가 계속 부각되고 있는데 점점 복잡해지는 산업 구조에 소프트웨어가 차지하는 비중도 커지기 때문일 것도 같습니다. 소프트웨어 안전성에 대한 이슈도 더 커지는 것 같고요. 오늘 이야기를 정리해 주시죠.

소프트웨어는 이제 소프트웨어를 만드는 회사나 개발자만 고민해서는 안됩니다. 거의 모든 산업에서 소프트웨어를 사용하고 있고 소프트웨어로 인해 문제가 발생하고 발전도 이룹니다. 소프트웨어의 역할이 그만큼 커졌다는 말이겠죠. 소프트웨어로 인한 안전 사고도 계속 발생할 것으로 보이기 때문에 소프트웨어에 대한 안전성 이슈도 대두될 것이고요. 소프트웨어공학은 이러한 이슈나 문제를 해결하기 위해 반드시 필요한 것이라고 인식해야 합니다. 소프트웨어가 원하는 대로 잘 개발되게 하고 문제가 발생하지 않게 하기 위해서는 소프트웨어공학을 얼마나 잘 적용했느냐 하는 것이 중요하기 때문입니다. 소프트웨어공학에 대한 각 산업의 이해가 더 필요한 시점인 것 같습니다.

Keyword: software engineering, software safety, fourth industrial revolution, software development

[218호 웹진: 공학 트렌드] 클라우드 SW 사례 연구 - 보안

클라우드 SW 사례 연구 - 보안

클라우드 서비스가 전통적인 소프트웨어 시스템을 대체하면서 가장 크게 이슈화된 것이 보안이다. 전통적인 소프트웨어 시스템은 구현 초기부터 보안에 대한 분석과 설계를 함께 하게 되는데 클라우드는 네트워크 자체가 외부에 오픈되어 있는 경우도 많고 가상화나 공유되는 부분도 많아 보안 문제가 항상 노출되어 있다. 하지만 클라우드 서비스도 소프트웨어 시스템의 일종이기 때문에 기존 보안 기술을 적절히 사용한다면 큰 보안 문제는 나타나지 않을 것으로 보인다. 이번 회에서는 클라우드 서비스의 보안에 대해 살펴보기로 한다.

사례 전 확인 사항

클라우드(Cloud) 보안 개념

클라우드 서비스는 시스템 내부의 자원을 사용하지 않고 외부의 자원을 일부나 전부를 사용하는 경우가 많아 보안에 대한 대비가 반드시 필요하다. 클라우드 보안 문제도 전통적인 소프트웨어 시스템의 보안 문제와 유사한 데이터 유출이나 안정성, 네트워크 문제, 그리고 가용성에 따른 서비스 문제 등이 있다(표1).

<표1> 클라우드 서비스의 보안 위협

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드 서비스에서 보안 문제가 더 크게 대두되는 문제는 그림1에서 보는 것처럼 전통적인 소프트웨어 시스템에서는 각 시스템 단위로 보안 문제를 준비하면 되기 때문에 자체적인 보안 가이드에 따라 보안 준비가 가능했지만 클라우드는 외부 네트워크로 연결되어 서비스가 되기 때문에 보안이 외부에 직접적으로 노출되어 있기 때문이다.

<그림1> 전통적인 소프트웨어 시스템과 클라우드 서비스의 비교

출처: 미래창조과학부

클라우드 서비스의 보안은 두가지 관점이 공존한다. 다양한 기업의 정보나 네트워크가 몰려 있기 때문에 보안 사고가 나타나면 여파가 굉장히 크다는 것과 기업이 자체적인 보안보다 체계적인 관리를 하기 때문에 더 안전하다는 관점도 있다. 특히 인프라(IaaS), 플랫폼(PaaS), 그리고 소프트웨어(SaaS)에 따라 보안이 구성되기 때문에 서비스 특성에 따른 맞춤형 보안도 장점 중 하나다. 또 다양한 시스템을 효율적인 구성으로 서비스하는 클라우드는 자원을 빌려 쓰는 개념이다 보니 비용적 측면이나 운영적 측면에서도 매우 효과적이고 보안 사고가 날 경우에도 클라우드 업체와 이용 업체가 책임을 나눌 수 있다는 점에서도 보안 부담이 줄어드는 것도 사실이다.

클라우드 보안 요소

클라우드 보안은 보안 위협 종류와 서비스 방식에 따라 다양한 보안 대처 방법이 필요하기 때문에 이미 몇 년 전부터 보안 위협에 대비하기 위해 클라우드 발전법이 시행되었고 보안 가이드라인이 제정된 상태다. 해외에는 미국의 페드램프(FedRAMP), 싱가포르의 MTCS, 일본의 ASP.SaaS와 같은 클라우드 보안 인증 제도를 운영하고 있다. 우리나라의 경우 한국인터넷진흥원(KISA; Korea Internet & Security Agency)에서 클라우드 서비스를 위한 보안 가이드를 제시하고 있다(표2).

<표2> KISA의 클라우드를 위한 보안 가이드

출처: 한국인터넷진흥원, 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

표2를 살펴보면 전통적인 소프트웨어 시스템은 시스템과 네트워크, 데이터베이스와 같은 스토리지, 그리고 애플리케이션으로 구성되는데 클라우드 서비스는 전통적인 소프트웨어 시스템을 일부 또는 전체를 대체하는 서비스이기 때문에 전통적인 소프트웨어 시스템의 보안 기준과 크게 차이가 나지 않는 것이 특징이다(표3).

<표3> 클라우드 서비스의 보안 기술

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드가 보안에 취약한 가장 큰 이유는 방화벽이나 네트워크 연결 등으로 제한할 수 있는 전통적인 소프트웨어 시스템에 비해 원격 접속을 허용해야 하는 속성과 클라우드 사용에 필요한 소프트웨어를 설치해야 하기 때문이다. 그리고 클라우드 서비스 업체는 보안 문제가 발생해도 외부에 공개하지 않고 처리하는 경우도 많기 때문에 보안 이슈에 대한 정보 공유도 아쉬운 것이 사실이다.

이러한 문제를 해결하기 위해서는 기존 소프트웨어 시스템의 보안 가이드나 보안 기술들을 적용해 보안 위협을 확인해야 하고 클라우드 서비스에서 독특하게 사용되는 가상화 기반 환경에 대해 집중적인 보안 위협 확인이 필요하다(그림2).

<그림2> 클라우드 가상화 기반의 보안 취약점

출처: Tech M

사례 연구

AWS(Amazon Web Services)

출처: https://www.slideshare.net/awskorea/intro-of-aws-cloud-usecase-and-strategy-61567540

AWS는 한 대의 독립된 컴퓨터를 제공하는 EC2, 파일 서버를 제공하는 S3, 데이터베이스를 제공하는 RDS 등의 서비스를 제공한다. 이러한 서비스를 조합해서 웹서비스(Web Service)를 만들게 된다(그림3). 빌딩 블록을 조립하듯이 비즈니스 요구사항에 따라 40여 개 이상의 서비스를 조립하여 유연하게 활용이 가능하다.

<그림3> AWS에서 제공하는 서비스

출처: Amazon

AWS는 세가지 방법으로 사용이 가능한데 웹서비스를 이용하는 AMC(AWS Management Console), 명령어 입력 방식인 CLI(Command Line Interface), 프로그래밍 언어 단위로 개발 API를 제공하는 SDK(Software Development Kit)가 있다. 명령어에 익숙하지 않다면 AMC를 우선적으로 사용하면 된다.

탄력적인 웹 트래픽 관리를 위한 AWS 사용은 그림4와 같이 구성할 수 있는데 로드밸런싱이나 오토스케일링을 통해 서버 부하 문제를 줄일 수 있고 확장성이 용이하다. 이러한 구성을 통해 웹사이트 리뉴얼이 용이하고 트래픽에 따라 최적의 성능이 발휘될 수 있어 AWS 구성에 따른 비용 절감 효과가 뛰어나다고 소개하고 있다.

<그림4> 웹 프래픽 관리를 위한 AWS 구성 예

출처: Amazon

그림5는 최근에 많이 적용되고 있는 빅데이터 관련 구성이다. 빅데이터 분석을 위해 수집과 저장, 분석 모듈에 필요한 AWS 컴포넌트를 사용하고 있다. 빅데이터 분석을 위해 자체적인 모듈이 사용된 경우 그림5에서 해당 모듈을 추가 적용해서 사용하면 된다.

<그림5> 빅데이터 분석을 위한 AWS 구성 예

출처: Amazon

그림6은 그림5의 빅데이터 분석을 위한 AWS 구성을 게임 빅데이터 분석에 적용한 예다. 게임 로그 데이터를 EC2와 S3를 거쳐 하둡(Hadoop)으로 구성된 EMR에서 분석하고 수분 내에 데이터 분석이 완료되도록 구성되어 있다.

<그림6> AWS의 빅데이터 분석을 게임 빅데이터 분석에 적용한 예

출처: Amazon

아마존에서는 기존 소프트웨어 시스템에서 클라우드로 전환하여 서비스하는 형태가 아닌 클라우드에서 신규 서비스를 직접 개발하는 전략을 수립하도록 권장하고 있는데 빠르고 저렴한 비용으로 개발과 배포가 가능하도록 서비스를 구성하고 있다. 이러한 서비스 제공은 다른 클라우드 서비스 업체에서도 제공하는 형태지만 특정 서비스 형태 뿐만 아니라 전체적인 클라우드 서비스를 한 곳에서 모두 제공한다는 점에서 장점이 있다.

또 아마존에서는 기존 소프트웨어 시스템에서 전환하거나 신규 서비스를 제공하더라도 유용한 기능만 우선 적용하도록 권장하고 있는데 자체적으로 구성해도 큰 무리가 없는 시스템까지 모두 클라우드로 전환할 필요는 없다는 이유 때문이다. 클라우드 서비스는 서비스 단위의 모듈 형태로 제공되기 때문에 전체 서비스를 도입할 필요는 없어 기존 인프라나 자체적으로 구성이 가능한 서비스는 그대로 두고 클라우드와 역할을 분리하여 구성하는 것이 좋다(그림7).

<그림7> 하이브리드 클라우드 서비스의 예

출처: Amazon

기대 효과와 결론

클라우드 보안의 경우 기존 서비스와 크게 차이를 보이지 않기 때문에 가급적 기존 보안 가이드나 보안 기술을 이용해 보안 구성을 하는 것이 일차적인 목표다. 이렇게 구성된 보안 기준에 클라우드를 적용해서 나타나는 보안 요소에 대해서는 적용하는 클라우드 서비스 업체가 자세히 상의하는 것이 가장 현명한 방법이다. 클라우드는 기존에 만들어진 형태에 새롭게 만드는 것이 아니고 내가 가진 서비스와 조립을 하는 형태이기 때문이다. 조립에서 나타날 수 있는 보안 요소에 대해 철저히 확인한다면 클라우드 적용으로 인해 발생할 수 있는 보안 문제를 줄일 수 있을 것이다.

Keyword: software engineering, cloud service, paas, saas, iaas, amazon web service, cloud software architecture, cloud security