2017.06.01

하이브리드 클라우드 : 구축부터 데이터 암호화와 보안이 필요한 이유

BrandPost Sponsored by HPE
HPE | HPE


엔터프라이즈 데이터와 애플리케이션을 하이브리드 클라우드로 옮겨놓는 작업까지는 안전하게 완료할 수 있지만, 프로젝트가 성공하려면 IT 리더들이 더 깔끔한 소프트웨어 개발 프로세스를 구현하고, 사전 릴리즈 보안 시험을 개선해야 하며, 종합적인 데이터 암호화 프로세스를 포함해야만 합니다.

이제는 IT 책임자들이 소프트웨어에 설계에 대한 사고방식을 바꿔야 할 시점입니다. 개발자들이 애플리케이션을 설계하고 구축한 다음, 프로세스 마지막 단계에서 보안 취약점을 시험하는 대신, 더욱 신중하게 소프트웨어를 구축해서 애초부터 필요한 보안 패치와 수정작업을 줄이도록 권장하십시오. 그 다음에는 제대로 한 보상을 하십시오. 책임자들은 철저하게 변화할 필요가 있습니다.

이것이 바로 취약성을 초래하는 코딩 오류를 최소화하고, 주목할 정도로 개발과 유지보수 비용을 줄여주며, 더 낫고 더 안전한 코드를 생성하는 사고방식인 ‘보안을 고려한 설계(Security by Design, 이하 SbD)’입니다. 파괴적인 보안 침해를 줄이는 소프트웨어가 바로 SbD의 결과물입니다.

아주 처음부터 보안을 생각하십시오
“이런, 잘 알고 있을 줄 알았는데.” 흔히들 이렇게 생각하지만, HPE의 디지털 솔루션 및 트랜스포메이션 팀의 수석 기술자인 사이먼 리치는 이런 반응은 IT 보안 관리자와 소프트웨어 개발 책임자가 지금껏 취해온 방식이 아니라고 말합니다. 소속 기업이 하이브리드 클라우드로 이전하고 있다면, 인프라 비용 절감이나 IT 시스템 일부분의 간소화 그 이상에 대해서 관심을 가져야 합니다. 비즈니스를 클라우드로 이끌고 있는 모든 사용자는 고객과 사용자에 대한 비즈니스 데이터를 보호하기 위해 만전을 기해야만 합니다.

리치는 “애플리케이션 생명주기 초기에 보안에 대해 생각하지 않으면, 많은 분제가 돌연 발생합니다. 애플리케이션을 개발하는 것은 사람입니다. 그러므로 취약점으로 이어질 수 있는 실수는 늘 생기기 마련입니다”라고 설명했습니다.

적절한 데이터 암호화 프로세스와 더불어, 코드 창출을 위해 보안을 고려한 설계 접근방식을 적용함으로써, 기업들은 스스로의 IT 보안 운영을 고양할 수 있습니다. 조직이 전심전력으로 또는 하이브리드 클라우드 전략과 협력하여 클라우드 컴퓨팅을 채택할 때에는 특히 중요합니다.

물론, 말처럼 쉽지는 않습니다. 문제가 매우 위협적일 수도 있습니다. 그렇지만 결국, 보안 문제는 관리될 수 있습니다.

잘 만들어진 소프트웨어일수록 강력한 데이터 암호화가 필요합니다
애플리케이션은 클라우드로 아웃소싱 할 수 있지만, 위험은 아웃소싱 할 수 없습니다. 그래서 위험 분석을 실시하는 것이 중요합니다. 리치는 “데이터를 클라우드에 둘 수 있는지, 그리고 클라우드에 둘 경우 적절하게 보호되는지를 확인하십시오”라고 조언했습니다.

바로 이 부분에서 데이터 암호화가 개입합니다. 은행, 보험 회사, 그리고 의료서비스 공급업체처럼 규제된 산업계는 모두 암호화와 다른 보안 도구로 데이터를 보호할 때 충족해야 할 요구사항이 있습니다. 예를 들어, 2018년 5월부터 시행될 EU의 GDPR(General Data Protection Regulation: 개인 정보 보호 규정)을 생각해봅시다. 리치는 “이런 회사들이 침해를 당해서 데이터가 시중에 풀리면, IT 산업에 속한 비즈니스의 경우 그걸로 게임이 끝납니다”라고 부연했습니다.

자사 프라이빗 그리고 퍼블릭 클라우드 인프라–온프레미스, 클라우드, 또는 하이브리드까지–를 보호하기 위해 IT 리더들은 많은 도구와 프로세스를 필요로 합니다. 대개, 암호화가 중요한 최종 방어선입니다. 공격자들이 방화벽, 강화된 하드웨어, 또는 다른 방어책을 통과하더라도, 암호화 되어 있다면, 공격자들이 데이터에 액세스했더라도 그 데이터를 읽을 수 없기 때문입니다.

최근의 데이터 유출 사례를 살펴보면 강력한 데이터 암호화에 대한 논쟁을 이해하기 쉽습니다. 예를 들면, 2016년 5월, 링크드인은 2012년까지 거슬러가서, 1억 6,700만개의 사용자 계정에 영향을 준 데이터 유출 사고를 발표했습니다. 사용자 계정 암호는 ‘솔팅(Salting)’(흔히 사용되는 암호에 대한 해시를 개개 사용자 별로 고유하게 만들어주는 것)이 되지 않은 “해시(Hash)” 암호 저장 포맷으로 저장되어 있었습니다. 해싱은 정보를 스크램블 하기 위해 사용되는 수학 함수이지만, 보안을 보장하기 위해 암호 솔팅 같은 다른 단계도 필요로 합니다.

리치는 많은 기업이 각자 IT 시스템에 비슷한 취약점을 가지고 있으면서도 미처 문제를 인식하지 못할 수 있다고 말했습니다. 예를 들면, 자체 개발한 구형 애플리케이션에 결코 클라우드에서 사용될 의도가 아니었던 신용 카드 처리 애플리케이션이 포함되어 있을 수도 있습니다. 원래, 해당 애플리케이션이 민감한 데이터를 평문으로 저장했을 수도 있기 때문에, 암호화를 도입하는 것이 분명 필요할 것입니다. 그렇지만, 기업이 표준 암호화 알고리즘을 사용해서 신용 카드 번호를 암호화할 때, 암호화 알고리즘이 신용 카드 번호를 바꿔 고정 길이 데이터만 다루는 구형 애플리케이션이 해석하거나 처리할 수 없는 훨씬 긴 문자열로 놓으면 예기치 못한 문제가 발생할 수 있습니다.

그렇지만 암호 보호, ID 시스템을 비롯한 다른 취약한 데이터가 마치 잘 보호된 내부 데이터 센터에 있는 것처럼 취급되면, 회사의 이름이 언론에 도배될 수 있는 새로운 기회가 생긴다. 클라우드에 맞게 업데이트 되었는지를 확인하기 위해서 소프트웨어를 재검토 해야만 한다 – 아니면 처음부터 올바른 방식으로 설계 되던지. 특히, 비즈니스 애플리케이션 전반에 대한 데이터 호환성을 유지하기 위해 암호화에 대한 서로 다른 접근방식들에 대해 생각해 보라.

리치는 예를 들어, 시스템들을 함께 작동시키기 위한, 특별한 FPE(Format Preserving Encryption: 형태 보존 암호화)는 암호화되어서 해커가 해독할 수 없는 16자리 신용 카드 번호를 유지하고, 동시에 데이터도 보호할 수 있다고 설명했습니다. 즉, “잘 설계된 애플리케이션이라면 사용자의 암호를 알지 못합니다다. 아는 것이라고는 사용자 암호에 대한 해시뿐입니다. 애플리케이션은 백엔드에서 관여하며, 그것도 암호를 저장할 때 프로그램 단계 수준일 가능성이 높습니다”라는 것입니다.

문제는 IT 임원들이 프로세스에 익숙하지 않기 때문에 문제가 일어난다는 사실을 기업이 흔히 인식도 못하고 있다는 점입니다. 해결책이 있을까요? 관련자를 참여하게 하는 것입니다. 리치는 “애플리케이션을 설계할 때 보안 담당자도 회의에 참석시키십시오”라며, “보안에 대해서 논의해야 할 사항들을 다시 한번 지적할 수 있습니다”라고 조언했습니다.

더 나은 코드는 엄청난 예산 절감 수단
소프트웨어 코드 오류의 대가는 충격적일 수 있으며, 해결 작업에 수반되는 작업량에나 사후 애플리케이션 패치에는 엄청난 자원이 듭니다.

리치는 버그의 심각도에 따라, “조직은 패치를 작성하고, 그것들을 시험한 다음에, 고객들에게 패치를 릴리즈할 계획을 세웁니다”라고 말했습니다. 이는 사용자들이 패치를 설치할 것이라고 가정하기 때문입니다. 클라우드에서 호스팅 되는 애플리케이션은 가령, 서버 기반 소프트웨어에서보다는 덜 문제가 되기는 하지만, IT 조직으로서는 여전히 많은 노력과 작업이 듭니다.

더 엄격하고 오류 발생이 덜한 코드를 수정할 때는 사후 단계보다 개발 단계에서 수정할 때 예산이 30배나 더 줄어든다고 리치는 말했습니다. 물론, 이는 보안을 넘어서는 소프트웨어 결함에 대해 맞는 말입니다. 그렇지만, 보안 관련 오류를 줄이거나 제거함으로써, 기업은 추가 도구 없이 자사의 IT 보안을 개선할 수 있습니다. 기업 위험 사유를 감안할 때, 이는 기업이 일상적인 스타일과 외양 수정사항들은 나중으로 미루고, 취약점을 수정사항의 최우선순위로 두어야 함을 의미합니다.

애플리케이션의 릴리즈를 미루는 것이 차라리 나을 때도 있습니다. 리치는 “너무나 심각해서 해당 제품을 외부로 배포해서는 안 될 수준인 문제도 있습니다”라고 말했습니다. 코드가 작성될 때 잠재적인 취약점을 신중하게 생각한 결과입니다. 또, 리치는 “개발자는 보안 담당자들이 아닙니다. 따라서 보안을 고려하도록 사고방식과 의식구조를 바꿔야 합니다”라고 덧붙였습니다.

리치는 개발자의 의식구조를 바꿈으로써 코드를 바꿀 수 있다고 부연했습니다. 이는 개발자의 목표가 단지 코드의 신속한 적용이 아니라, 처음부터 더 안전한 코드를 구축하고 여러 번 고민하는 것임을 의미합니다.

보안을 고려한 설계 사고방식은 아직 모든 곳에서 적용되지는 않지만, 점점 인기를 얻어가는 추세입니다. 그러나 누구도 보안을 고려한 설계를 만병통치약처럼 취급해서는 안 됩니다. SbD는 코딩 오류를 줄일 수는 있지만, 문제를 완벽하게 해결해주지는 않기 때문입니다. 리치는 “바로 이것이 하이브리드 클라우드 보안 시스템을 설계할 때, 암호화를 비롯한 다른 보안 단계들로 계층화해야만 하는 이유”라고 강조했습니다.

함께 묶기
보안을 고려한 설계는 애플리케이션 개발의 모든 요소에서 중요하지만, 특히 중요한 것은 하이브리드 클라우드 환경입니다. 암호화 역시 침입이 발생할 때 최종 방어선으로서 보호책을 제공할 수 있습니다.

리치는 “임원은 위험요소, 위협, 주의, 사용해야 할 플랫폼, 보안 관점에서 어느 방어책을 시행할 것인지 등을 모두 이해해야 합니다”라고 주장합니다. 또, “여기에는 암호화를 사용하지 않은 데에 따른 법적 책임과 위험도 포함됩니다. 확실히 검토하지 않고 모두 알고 있다고 가정하지 마십시오”라고 권고합니다.

보안을 고려한 설계 : 리더를 위한 교훈
- 각각의 클라우드 애플리케이션에 대해 적합한 암호화 유형을 신중하게 고려하십시오.

- 처음부터 제대로 소프트웨어를 구축하십시오. 나중에 수정하는 것보다 더 경제적입니다.

- 애플리케이션의 보안은 애플리케이션 설계 프로세스의 일부가 되어야 합니다. 물론 처음부터 병행해 수행되어야 합니다.


2017.06.01

하이브리드 클라우드 : 구축부터 데이터 암호화와 보안이 필요한 이유

BrandPost Sponsored by HPE
HPE | HPE


엔터프라이즈 데이터와 애플리케이션을 하이브리드 클라우드로 옮겨놓는 작업까지는 안전하게 완료할 수 있지만, 프로젝트가 성공하려면 IT 리더들이 더 깔끔한 소프트웨어 개발 프로세스를 구현하고, 사전 릴리즈 보안 시험을 개선해야 하며, 종합적인 데이터 암호화 프로세스를 포함해야만 합니다.

이제는 IT 책임자들이 소프트웨어에 설계에 대한 사고방식을 바꿔야 할 시점입니다. 개발자들이 애플리케이션을 설계하고 구축한 다음, 프로세스 마지막 단계에서 보안 취약점을 시험하는 대신, 더욱 신중하게 소프트웨어를 구축해서 애초부터 필요한 보안 패치와 수정작업을 줄이도록 권장하십시오. 그 다음에는 제대로 한 보상을 하십시오. 책임자들은 철저하게 변화할 필요가 있습니다.

이것이 바로 취약성을 초래하는 코딩 오류를 최소화하고, 주목할 정도로 개발과 유지보수 비용을 줄여주며, 더 낫고 더 안전한 코드를 생성하는 사고방식인 ‘보안을 고려한 설계(Security by Design, 이하 SbD)’입니다. 파괴적인 보안 침해를 줄이는 소프트웨어가 바로 SbD의 결과물입니다.

아주 처음부터 보안을 생각하십시오
“이런, 잘 알고 있을 줄 알았는데.” 흔히들 이렇게 생각하지만, HPE의 디지털 솔루션 및 트랜스포메이션 팀의 수석 기술자인 사이먼 리치는 이런 반응은 IT 보안 관리자와 소프트웨어 개발 책임자가 지금껏 취해온 방식이 아니라고 말합니다. 소속 기업이 하이브리드 클라우드로 이전하고 있다면, 인프라 비용 절감이나 IT 시스템 일부분의 간소화 그 이상에 대해서 관심을 가져야 합니다. 비즈니스를 클라우드로 이끌고 있는 모든 사용자는 고객과 사용자에 대한 비즈니스 데이터를 보호하기 위해 만전을 기해야만 합니다.

리치는 “애플리케이션 생명주기 초기에 보안에 대해 생각하지 않으면, 많은 분제가 돌연 발생합니다. 애플리케이션을 개발하는 것은 사람입니다. 그러므로 취약점으로 이어질 수 있는 실수는 늘 생기기 마련입니다”라고 설명했습니다.

적절한 데이터 암호화 프로세스와 더불어, 코드 창출을 위해 보안을 고려한 설계 접근방식을 적용함으로써, 기업들은 스스로의 IT 보안 운영을 고양할 수 있습니다. 조직이 전심전력으로 또는 하이브리드 클라우드 전략과 협력하여 클라우드 컴퓨팅을 채택할 때에는 특히 중요합니다.

물론, 말처럼 쉽지는 않습니다. 문제가 매우 위협적일 수도 있습니다. 그렇지만 결국, 보안 문제는 관리될 수 있습니다.

잘 만들어진 소프트웨어일수록 강력한 데이터 암호화가 필요합니다
애플리케이션은 클라우드로 아웃소싱 할 수 있지만, 위험은 아웃소싱 할 수 없습니다. 그래서 위험 분석을 실시하는 것이 중요합니다. 리치는 “데이터를 클라우드에 둘 수 있는지, 그리고 클라우드에 둘 경우 적절하게 보호되는지를 확인하십시오”라고 조언했습니다.

바로 이 부분에서 데이터 암호화가 개입합니다. 은행, 보험 회사, 그리고 의료서비스 공급업체처럼 규제된 산업계는 모두 암호화와 다른 보안 도구로 데이터를 보호할 때 충족해야 할 요구사항이 있습니다. 예를 들어, 2018년 5월부터 시행될 EU의 GDPR(General Data Protection Regulation: 개인 정보 보호 규정)을 생각해봅시다. 리치는 “이런 회사들이 침해를 당해서 데이터가 시중에 풀리면, IT 산업에 속한 비즈니스의 경우 그걸로 게임이 끝납니다”라고 부연했습니다.

자사 프라이빗 그리고 퍼블릭 클라우드 인프라–온프레미스, 클라우드, 또는 하이브리드까지–를 보호하기 위해 IT 리더들은 많은 도구와 프로세스를 필요로 합니다. 대개, 암호화가 중요한 최종 방어선입니다. 공격자들이 방화벽, 강화된 하드웨어, 또는 다른 방어책을 통과하더라도, 암호화 되어 있다면, 공격자들이 데이터에 액세스했더라도 그 데이터를 읽을 수 없기 때문입니다.

최근의 데이터 유출 사례를 살펴보면 강력한 데이터 암호화에 대한 논쟁을 이해하기 쉽습니다. 예를 들면, 2016년 5월, 링크드인은 2012년까지 거슬러가서, 1억 6,700만개의 사용자 계정에 영향을 준 데이터 유출 사고를 발표했습니다. 사용자 계정 암호는 ‘솔팅(Salting)’(흔히 사용되는 암호에 대한 해시를 개개 사용자 별로 고유하게 만들어주는 것)이 되지 않은 “해시(Hash)” 암호 저장 포맷으로 저장되어 있었습니다. 해싱은 정보를 스크램블 하기 위해 사용되는 수학 함수이지만, 보안을 보장하기 위해 암호 솔팅 같은 다른 단계도 필요로 합니다.

리치는 많은 기업이 각자 IT 시스템에 비슷한 취약점을 가지고 있으면서도 미처 문제를 인식하지 못할 수 있다고 말했습니다. 예를 들면, 자체 개발한 구형 애플리케이션에 결코 클라우드에서 사용될 의도가 아니었던 신용 카드 처리 애플리케이션이 포함되어 있을 수도 있습니다. 원래, 해당 애플리케이션이 민감한 데이터를 평문으로 저장했을 수도 있기 때문에, 암호화를 도입하는 것이 분명 필요할 것입니다. 그렇지만, 기업이 표준 암호화 알고리즘을 사용해서 신용 카드 번호를 암호화할 때, 암호화 알고리즘이 신용 카드 번호를 바꿔 고정 길이 데이터만 다루는 구형 애플리케이션이 해석하거나 처리할 수 없는 훨씬 긴 문자열로 놓으면 예기치 못한 문제가 발생할 수 있습니다.

그렇지만 암호 보호, ID 시스템을 비롯한 다른 취약한 데이터가 마치 잘 보호된 내부 데이터 센터에 있는 것처럼 취급되면, 회사의 이름이 언론에 도배될 수 있는 새로운 기회가 생긴다. 클라우드에 맞게 업데이트 되었는지를 확인하기 위해서 소프트웨어를 재검토 해야만 한다 – 아니면 처음부터 올바른 방식으로 설계 되던지. 특히, 비즈니스 애플리케이션 전반에 대한 데이터 호환성을 유지하기 위해 암호화에 대한 서로 다른 접근방식들에 대해 생각해 보라.

리치는 예를 들어, 시스템들을 함께 작동시키기 위한, 특별한 FPE(Format Preserving Encryption: 형태 보존 암호화)는 암호화되어서 해커가 해독할 수 없는 16자리 신용 카드 번호를 유지하고, 동시에 데이터도 보호할 수 있다고 설명했습니다. 즉, “잘 설계된 애플리케이션이라면 사용자의 암호를 알지 못합니다다. 아는 것이라고는 사용자 암호에 대한 해시뿐입니다. 애플리케이션은 백엔드에서 관여하며, 그것도 암호를 저장할 때 프로그램 단계 수준일 가능성이 높습니다”라는 것입니다.

문제는 IT 임원들이 프로세스에 익숙하지 않기 때문에 문제가 일어난다는 사실을 기업이 흔히 인식도 못하고 있다는 점입니다. 해결책이 있을까요? 관련자를 참여하게 하는 것입니다. 리치는 “애플리케이션을 설계할 때 보안 담당자도 회의에 참석시키십시오”라며, “보안에 대해서 논의해야 할 사항들을 다시 한번 지적할 수 있습니다”라고 조언했습니다.

더 나은 코드는 엄청난 예산 절감 수단
소프트웨어 코드 오류의 대가는 충격적일 수 있으며, 해결 작업에 수반되는 작업량에나 사후 애플리케이션 패치에는 엄청난 자원이 듭니다.

리치는 버그의 심각도에 따라, “조직은 패치를 작성하고, 그것들을 시험한 다음에, 고객들에게 패치를 릴리즈할 계획을 세웁니다”라고 말했습니다. 이는 사용자들이 패치를 설치할 것이라고 가정하기 때문입니다. 클라우드에서 호스팅 되는 애플리케이션은 가령, 서버 기반 소프트웨어에서보다는 덜 문제가 되기는 하지만, IT 조직으로서는 여전히 많은 노력과 작업이 듭니다.

더 엄격하고 오류 발생이 덜한 코드를 수정할 때는 사후 단계보다 개발 단계에서 수정할 때 예산이 30배나 더 줄어든다고 리치는 말했습니다. 물론, 이는 보안을 넘어서는 소프트웨어 결함에 대해 맞는 말입니다. 그렇지만, 보안 관련 오류를 줄이거나 제거함으로써, 기업은 추가 도구 없이 자사의 IT 보안을 개선할 수 있습니다. 기업 위험 사유를 감안할 때, 이는 기업이 일상적인 스타일과 외양 수정사항들은 나중으로 미루고, 취약점을 수정사항의 최우선순위로 두어야 함을 의미합니다.

애플리케이션의 릴리즈를 미루는 것이 차라리 나을 때도 있습니다. 리치는 “너무나 심각해서 해당 제품을 외부로 배포해서는 안 될 수준인 문제도 있습니다”라고 말했습니다. 코드가 작성될 때 잠재적인 취약점을 신중하게 생각한 결과입니다. 또, 리치는 “개발자는 보안 담당자들이 아닙니다. 따라서 보안을 고려하도록 사고방식과 의식구조를 바꿔야 합니다”라고 덧붙였습니다.

리치는 개발자의 의식구조를 바꿈으로써 코드를 바꿀 수 있다고 부연했습니다. 이는 개발자의 목표가 단지 코드의 신속한 적용이 아니라, 처음부터 더 안전한 코드를 구축하고 여러 번 고민하는 것임을 의미합니다.

보안을 고려한 설계 사고방식은 아직 모든 곳에서 적용되지는 않지만, 점점 인기를 얻어가는 추세입니다. 그러나 누구도 보안을 고려한 설계를 만병통치약처럼 취급해서는 안 됩니다. SbD는 코딩 오류를 줄일 수는 있지만, 문제를 완벽하게 해결해주지는 않기 때문입니다. 리치는 “바로 이것이 하이브리드 클라우드 보안 시스템을 설계할 때, 암호화를 비롯한 다른 보안 단계들로 계층화해야만 하는 이유”라고 강조했습니다.

함께 묶기
보안을 고려한 설계는 애플리케이션 개발의 모든 요소에서 중요하지만, 특히 중요한 것은 하이브리드 클라우드 환경입니다. 암호화 역시 침입이 발생할 때 최종 방어선으로서 보호책을 제공할 수 있습니다.

리치는 “임원은 위험요소, 위협, 주의, 사용해야 할 플랫폼, 보안 관점에서 어느 방어책을 시행할 것인지 등을 모두 이해해야 합니다”라고 주장합니다. 또, “여기에는 암호화를 사용하지 않은 데에 따른 법적 책임과 위험도 포함됩니다. 확실히 검토하지 않고 모두 알고 있다고 가정하지 마십시오”라고 권고합니다.

보안을 고려한 설계 : 리더를 위한 교훈
- 각각의 클라우드 애플리케이션에 대해 적합한 암호화 유형을 신중하게 고려하십시오.

- 처음부터 제대로 소프트웨어를 구축하십시오. 나중에 수정하는 것보다 더 경제적입니다.

- 애플리케이션의 보안은 애플리케이션 설계 프로세스의 일부가 되어야 합니다. 물론 처음부터 병행해 수행되어야 합니다.


X