![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Obama 행정부는 최신 Web 2.0과 클라우드 컴퓨팅 기술을 사용하여 정부 서비스를 개선하는 데 특히 초점을 맞췄다. 이러한 요청은 다음 몇 년 동안 예산에 반영되었으며 그 결과 모든 기관은 공식적으로 그리고 법률에 따라 클라우드를 먼저 고려해야 한다. 이러한 클라우드 우선 정책 덕택에 의미 있는 데이터 센터 통합 분석 노력이 수행 중이며 Obama 행정부는 클라우드 채택을 가속화할 수 있는 방법을 찾고 있다. 물론, 행정부에서 추진하는 클라우드 컴퓨팅으로의 대규모 이동은 여러 해에 걸쳐 수행될 이니셔티브이지만 개념적으로는 정부의 최상위 IT 지도부가 이동할 준비가 되었음이 분명하다.
클라우드로 이동하는 데 따른 기술적 이점과 이와 관련된 비즈니스 케이스는 예산 절약 가능성과 문제점의 규모가 훨씬 더 크다는 점을 제외하면 정부와 기업이나 모두 동일하다. 정부가 다음 수 년 동안 정부 예산의 5퍼센트를 줄일 수 있으면 수십억 달러의 예산을 절약할 수 있게 된다는 점에서 정부의 고위급 IT 리더가 클라우드를 고려하는 이유를 쉽게 이해할 수 있다.
일반적인 클라우드 비즈니스 과제는 대부분 다른 환경에서도 동일하지만 정부에는 몇 가지 특수한 과제가 있다. 첫 번째 과제는 조달과 관련된다. 무언가에 대한 수요를 모르는 상태에서 정부가 미리 년간 예산을 책정하는 경우, On Demand 클라우드 서비스를 어떻게 구입해야 할까? 정부는 모든 기관의 요구에 적합하고 장기적인 목적에 맞는 소수의 계약을 협상하려고 하기 때문에 계약과 조달 프로세스는 일반적으로 길고 힘들다. 이러한 프로세는 장기 계약으로 진행되기 때문에 기술 혁신 주기를 쉽게 앞지르게 된다. 따라서 정부는 이전의 비싼 서버와 네트워크, 데이터 센터 등을 구입하지 않게 된다.
조달과 문화적 구입 장벽이 중요하지만 두 번째로 가장 중요한 장벽은 클라우드에서의 보안이며 이것은 상업적 회사이지만 정부와 매우 밀접한 관계가 있고 규모가 큰 회사의 경우에도 마찬가지이다. 정부가 고수해야 하는 보안 규칙은 일반적으로 의회가 법적 효력이 있는 공식 규정으로 작성한다. 따라서 보안 규칙은 상업적 회사의 규칙보다 훨씬 더 엄격하고 덜 관대하다.
클라우드로 이동함으로써 얻을 수 있는 전체적인 보안상의 이점
많은 정부 기관이 사설 데이터와 공용 데이터(시민들과 공유하는 보호되지 않은 데이터)를 논리적으로 동일한 네트워크에서 호스트한다. 공용 서버와 사설 서버는 서로 인접한 위치에 있지 않기 때문에 공용 데이터를 외부 클라우드로 이동함으로써 정부 기관은 내부의 민감한 데이터가 노출되지 않도록 할 수 있다.
오늘날 각 정부 기관은 자체 네트워크를 보유하고 있으며 아마도 동일한 작업을 수행하는 수 백 개의 다양한 네트워크를 설계하고, 빌드하고, 문서화하고, 보호하고, 모니터하고 감사하는 데 사실상 수 십만 달러를 소비한다. 클라우드로 이동하게 되면 인프라와 네트워크가 유사해지거나 동일해지기 때문에 보안 감사 및 테스트와 같은 관련 태스크가 더 간단해진다.
애플리케이션, 플랫폼 및 네트워크의 현재 구조를 감안하면 대부분의 기관에서 리던던시 및 재해 복구(DR)나 업무 연속성(COOP)에 비용이 매우 많이 들어간다. 클라우드에서는 백업하기가 더욱 쉽고 리던던시 기능이 우수하기 때문에 클라우드로 이동하여 무엇보다도 가상화 기술을 활용하게 되면 DR과 COOP 전략을 더욱 쉽게 구현할 수 있다.
DR과 COOP가 더욱 수월해지는 이유는 믿을만한 클라우드 벤더는 모두 중복 데이터 센터를 다수 갖추고 있고 다수의 사이트에 가상의 시스템을 복제하는 기능을 제공하기 때문이다. 간과하기 쉬운 점은 백업이 더욱 간편해진다는 사실이다. 다시 말해서 많은 벤더들이 다수의 디스크 드라이버를 이용해 데이터 리던던시를 구현하기 위해 SAN(Storage Area Network)을 제공하기 때문에 실시간 백업이 가능하다. 이외에도 벤더에서는 롤백할 수 있는, 전체 디스크의 정규 백업용 스냅샷을 제공하며 해당 서비스를 구입하는 경우에는 이 스냅샷을 이용하여 원격지 스토리지나 테이프로 데이터를 이동할 수 있다. DR과 백업 전략이 잘못되면 데이터 손실이나 데이터 누설이 발생할 수 있기 때문에 DR, COOP 및 백업 오퍼링은 단지 기술적인 기능에 불과한 것이 아니라 중요한 보안 고려사항이 된다.
클라우드로 이동하게 되면 몇 가지 이점을 활용할 수 있는데도 대부분의 IT 전문가는 다양한 이유를 들어 클라우드로 이동하기를 망설인다. 보안 전문가들이 일반적으로 질문하는 사항은 다음과 같다.
- 벤더의 보안 모델이 신뢰할 수 있는 것인지 어떻게 알 수 있나? 문서 작업과 프로세스가 명확하게 진행되는가? 벤더에서 감사 결과에 대응할 것이라는 점을 어떻게 아나?
- 결함을 확인하기 위해 벤더의 사설 구현물을 쉽게 시험할 수 있나? 현재, 사용 중인 네트워크 내에서 수행할 수 있는 방식과 동일한 방식으로 침입 탐지나 범죄 수사를 지원하나?
- 정부에서 이용하는 인터넷 트래픽 대역폭을 완전히 감사하는 TIC(Trusted Internet Connection)를 지원하나? TIC는 위임되어 있으며 클라우드 제공업체는 대부분 TIC를 알지도 못한다.
- 기밀 취급을 받지 않는 시스템으로 기밀 데이터가 누설되는 것을 어떻게 추적하나? 기밀 정보가 기밀 취급을 받지 않는 시스템으로 우연하게 "누설"되는 경우, 정보가 누설된 후에 정부 담당자가 벤더의 시설에 와서 전체 하드 드라이브에 있는 데이터를 완전히 삭제하여 정리하도록 벤더에 요청할 수 있다. 하나의 하드 드라이브에서 여러 고객의 데이터를 공유한 경우, 하드 드라이브에 있는 데이터를 삭제하기 위해서는 어떤 프로세스를 수행해야 하는가? 기밀 데이터와 기밀 취급을 받지 않는 데이터를 혼합한 책임과 관련된 문제점은 어떻게 해결하나?
- 정부 데이터가 실제로 미국 본토에 있는 서버에 있다는 것을 어떻게 보장하나? 의회에서 작성한 엄격한 규칙과 이러한 규정이 반드시 필요한 다양한 대통령 산하 기관에서 제정한 규정이 있다.
- 백업이 벤더의 시스템 경계 밖에서 이루어지는가? 데이터가 보안 연결을 통해 전송되고 원격지에서 암호화되는가? 원격지로 이전하는 과정에서 데이터가 암호화되는가? 원격지에서 물리적 보안과 기술적 보안을 제어하는 것은 무엇인가? 원격지에 저장하기 위해 백업 데이터를 외부 장소로 전송하는가? 동일하게 보안이 통제되는 백업 사이트가 기본 사이트인가?
이러한 질문은 대부분 멀티 테넌시, 암호화 및 규정 준수 문제와 관련되어 있으며 결국은 신뢰성 문제로 귀결된다. 대부분의 클라우드 벤더는 더욱 다양한 질문에 쉽게 대답할 수 있다. 정부에 서비스를 제공하고자 하는 클라우드 벤더이거나 어떤 기술적 보안 문제에 집중해야 하는지 알고 싶은 정부 구매 담당자라면 여기에 있는 몇 가지 조언을 참고하도록 하자. 이 기사에서는 정부의 관점에서 보안 위협을 다루게 되지만, 스마트 클라우드 벤더라면 정부에서 벤더에게 어떠한 질문을 하게 될지 미리 살펴보고 적절하게 준비한다는 관점에서 보안 위협을 살펴볼 수 있다.
그다음에는 정부 클라우드 사용자를 위한 특정 보안 과제를 살펴본다.
아프가니스탄 전쟁과 관련된 기밀문서 9만 페이지가 유출된 최근의 사건을 초래한 악의적인 내부자와 같은 다양한 위협을 알고 싶어하는 것이 일반적이다. 적절한 ID 관리와 액세스 제어는 단일 엔티티의 IT 시스템 경계 내에서도 이미 어렵다. 그러나 내부 네트워크에 있게 될 부분과 다른 벤더의 환경 내에 있는 클라우드에 있게 될 부분(규모의 크기와 상관 없이)이 혼재되어 시스템 간의 경계가 없어지면 적절하게 ID를 관리하고 액세스를 제어하기가 훨씬 더 어려워진다. 이러한 하이브리드 시스템을 안전하게 유지하려면 클라우드 벤더의 고용 사례를 생각해 보아야 한다. 클라우드 벤더는 적어도 독자의 자체 정책만큼이나 엄격한 고용 정책을 갖추고 있다. 데이터를 처리하거나 시스템을 조작하는 개인이 언제 들어오고 나가는지 그리고 이들이 어떤 상황에서 떠났는지 벤더는 어떻게 알려줄까? 벤더의 직원을 신뢰할 수 없으면 벤더를 신뢰할 수 없게 된다. 예를 들면, 클라우드 벤더의 직원이 떠날 때, 관련 사실을 통보 받았는가?
일단, 고용 프로세스와 시스템 프로비저닝 규칙을 확실히 알고 있으면 벤더의 논리적 액세스 권한과 액세스 권한 상승 프로세스를 이해하고 싶을 것이다. 누가 액세스 규칙을 결정하며 액세스 규칙이 변경되는 시점이 어떻게 통보되나? 사람들은 초기 액세스 권한을 부여하는 작업에 가장 많은 관심을 보인다. 그렇지만 위반 행위는 벤더에서 기존 직원의 액세스 권한을 올렸지만 이러한 사실을 통보 받지 못한 경우에 발생할 가능성이 높기 때문에 별도로 사용을 모니터할 수 있다는 점을 기억해야 한다. 정부에 나가 있는 자체 직원의 ID와 액세스 권한을 모니터하는 것이 중요하지만 2요인 인증이 필요한 원격 액세스용 VPN이나 네트워크에 접근하는 데 필요한 온프레미스(on-premise) 물리적 보안과 같은 기타 보호 수단이 있다. 보안면에서 보면 클라우드 벤더의 직원은 자체 직원과 마찬가지이며, 클라우드 벤더의 직원이 내부 직원과 동일한 규칙을 따르지 않는 경우에는 조만간 틀림없이 위반 행위가 일어나게 된다.
이러한 위험을 해결하기 위한 특별 수단으로 계약상의 의무에 따라 확인하고 추적할 수 있는 클라우드 제공업체 주요 직원의 목록을 작성하고자 할 수도 있다. 정보에 대한 액세스 권한을 정기적으로 감사하는 것도 일반적으로 사용하는 기술이다. 준수 보고서와 모니터링 도구를 적절하게 시행하도록 하여 계약을 감독하는 정부 직원이 클라우드 벤더의 프로세스를 완전히 이해할 수 있게 해야 한다. 2요인 보안을 요구하고 신임 정보를 공유하지 못하게 하는 것도 분명히 중요하지만 이러한 것은 파악하기 힘들다. 따라서 보안이 클라우드 벤더의 DNA에 있는지 아니면 벤더에서 준수 노력으로 여기는 무언가에 있는지 아는 것이 훨씬 더 중요하다.
IBM®, Amazon, Google, Microsoft®와 같은 유명한 회사들은 이미 이러한 보안 작업을 처리하는 방법을 알고 있으며 걱정스러운 것은 시스템에 집중하기보다는 애플리케이션에 집중해온 SaaS(Software as a Service)나 PaaS(Platform as a Service) 벤더이다. 클라우드 벤더가 정부나 엔터프라이즈에 집중하기보다 소비자에게 더 집중하게 되면 정부에 돌이킬 수 없는 문제를 일으킬 수 있는 미션 크리티컬 데이터를 많이 다루지 않게 되므로 더욱 세밀하게 조사할 필요가 있다.
다양한 종류의 지적 재산을 보호해야 하지만 데이터가 가장 중요하다는 사실은 변함이 없다. 보안을 생각하면서 사람들이 서버나 애플리케이션을 훔칠 거라고 생각하지는 않기 때문이다. 진정으로 신경 써야 할 대상은 서버에 저장된 데이터이며 특히, 정부의 경우에 그렇다. 데이터 침해는 데이터 손실을 일으킬 수 있으며 원본 데이터는 보존되지만 소스에서 복사되는 경우에는 데이터 누설이라고도 한다. 다음과 같은 다양한 원인 때문에 데이터 보안 침해가 일어날 수 있다.
- 데이터 소유자가 모르는 상태에서의 데이터 변경
- 회복할 수 없는 몇 가지 방법으로 데이터 삭제
- 좋지 않은 방법으로 데이터를 획득하고 이 데이터를 이용하여 정부나 시민에게 해를 끼치는 행위
국가 보안이 의미하는 바를 이미 알고 있을 것이다. 기밀 데이터가 누설되면 군인이 위험한 상태에 처할 수 있다. 그러나 상업적 해킹과 데이터 침해는 훨씬 더 자주 발생하기 때문에 반드시 방지해야 한다. 여기에서는 정부를 위해 일하는 계약자가 내부 정부를 이용하려고 하는 다른 계약자에게 제공하기 위해 민감한 조달 정보를 훔치거나 빌려갈 수 있다는 간단한 사례를 살펴본다. 모든 데이터와 사용자가 같은 네트워크에 있는 경우에는 이러한 데이터 누설을 추적하기 쉽지만 클라우드에서 이러한 데이터와 IT 시스템을 통제할 수 없는 경우에는 추적하기가 매우 어렵다.
데이터 누설 위험을 해결하려면 계약상 의무가 있는 클라우드 벤더가 액세스 로그를 유지하고 데이터베이스 서버(실제 시스템이나 가상 머신) 및 데이터베이스 시스템(MySQL, ORACLE, DB2® 등)과 같은 주요 시스템을 정기적으로 감사하는지 확인해야 한다. 예를 들면, 클라우드 벤더의 DBA 팀에서 어떤 데이터를 정기적으로 검사하고 관리하는지 알아야 한다. 클라우드 제공업체가 아직 이러한 정보를 추적하지도 않고 이와 관련해서 특별한 조치를 취하고 있지도 않다면 문제가 발생할 수 있다.
클라우드 보안은 기능 요구사항뿐 아니라 전체 시스템에 긴급하게 요구되는 특성이다. 보안을 기능상의 특정 요구사항으로 다루는 것은 보안을 위한 첫 걸음이다. 다시 말해서 구입하는 시스템과 선택하는 벤더는 틀림없이 "안전"해야 한다. 그러나 복잡한 시스템에서는 대부분 보안이 약간 긴급한 특성으로 인식되었으며 그 결과 시스템의 주요 부분이 기능적으로 안전해졌지만 전체 시스템은 여전히 안전하지 못하고 위험이 큰 상태로 남아있게 되었다. 예를 들면, 클라우드 벤더가 그들의 하드 드라이브에서 미사용 데이터를 암호화할 수 있으며(보안) 또한, 암호화된 방식으로 사이트 간에 데이터를 전송할 수도 있다(보안). 그러나 사용자가 자신의 비밀번호를 기록해 두거나 휴대전화에 저장할 수도 있다(비보안). 대부분의 보안 전문가들과 특히, 담당 임원은 컴포넌트를 서로 연결하는 인적 요인보다는 컴포넌트의 기술적 보안에 많은 시간을 소비하는 경향이 있으며 이 때문에 위험이 쉽게 간과된다. 이러한 사실은 완전히 다른 조직이 포함된 클라우드로 이동하는 경우에는 훨씬 더 심각하다. 보안과 이와 관련된 위험을 긴급 특성(시스템 내에 있는 것보다는 시스템에서 일어날 수 있는 것)으로 처리하게 되면 클라우드 보안 위협을 더욱 쉽게 관리할 수 있게 된다.
또 다른 해결 수단은 데이터 처리와 관계가 있다. 가장 일반적인 데이터 누설은 DBA가 데이터를 능동적으로 보호하는 과정에서는 거의 발생하지 않으며 하드 드라이브를 처분하거나 환경 간에 백업 테이프를 전달하는 경우 또는 재사용하기 위해 매체를 스케줄링하는 경우에 발생한다. 클라우드 벤더에서 데이터 보안을 추적하는 업무를 담당하게 되면 벤더에 데이터 처리 계획을 문의하고 조심스럽게 계획을 감사해야 한다.
직원에 대한 액세스 제어 및 데이터 처리와 같은 다양한 공격 벡터를 조사할 경우에는 서로 다른 클라이언트 간의 데이터 혼합과 멀티 테넌시 및 데이터를 보호하는 방법에 집중한다. 예를 들면, IaaS(Infrastructure as a Service) 제공업체에서 동일한 실제 서버에 액세스하는 5개의 클라이언트로 파티션된 VM을 제공할 수도 있다. 동일한 시스템에 있는 보호된 VM에서 다른 VM의 데이터를 액세스할 수는 있지만 매우 어렵다. 그러나 클라이언트 간에 데이터가 누설되지 않도록 멀티 테넌트 애플리케이션을 보호하기는 더 어려우며 데이터가 누설될 가능성이 더욱 증가한다. 클라우드 벤더에게 그들이 멀티 테넌트 데이터를 어떻게 저장하는지 그리고 한 테넌트(독자)가 다른 테넌트의 데이터를 우연히 또는 악의적으로 액세스할 가능성이 있는지 묻고 싶을 것이다. 대부분의 벤더와 프로그래머는 그들이 프로그램된 안전 수단을 갖추고 있다고 말하겠지만 HTML이나 Javascript 파일에 있는 액세스 로직의 단순한 버그로 인해 대용량 데이터가 누설될 수 있다. 논리적으로 그리고 물리적으로 하나인 데이터베이스에 모든 것을 저장하는 멀티 테넌트 시스템에서는 각 테넌트의 데이터를 고객별로 다양한 스키마를 사용하는 논리적으로 분리된 데이터베이스에 저장하는 시스템보다 이러한 오류가 더욱 많이 발생한다. 벤더와 긴밀하게 협력하여 데이터 누설 위험을 찾아내도록 한다. 데이터 누설 위험은 벤더에서 생각하는 것보다 훨씬 더 크다.
데이터 암호화 및 반투명 데이터베이스, 이 두 가지 기술은 비밀 정보를 처리하는 데 일반적으로 사용하는 방법이다. 벤더는 완전한 디스크 암호화나 부분적인 디스크 파일 시스템 기반 암호화, 스키마 기반 암호화, 테이블 암호화, 컬럼 암호화를 선택하거나 이들을 혼합해서 사용할 수 있다. 특정 데이터를 보호하는 데 적합하다면 최소한 FIPS 140-2 암호화를 사용해야 한다. ("Federal Information Processing Standards publication 140-2"에 대한 링크는 참고자료를 참조한다.) 벤더에서 다른 유형을 수행하는 방법을 실제로 이해하지 않는 한, 가장 좋은 방법은 전체 디스크 암호화를 보장하는 것이다. 그러나 클라우드 벤더가 데이터베이스의 유휴 데이터를 암호화했다고 하는 경우에도 벤더의 키 관리 방식을 확인해야 한다. 누가 키를 보관하며 키가 어떻게 관리되는가? 키를 안전하고 적절하게 관리하지 않으면 암호화는 아무런 의미가 없다. 일부 벤더는 위험을 인식하지 못하고는 디스크를 암호화하고 같은 서버에 암호 해독 키를 저장한다. 정부 데이터를 보호하는 것은 상업용 데이터를 보호하는 것보다 훨씬 더 어려움으로 벤더의 직원은 이점을 반드시 인식해야 한다. IaaS를 사용할 경우에는 암호화와 키 관리 수준을 원하는 정도로 제어할 수 있다. 그러나 PaaS나 SaaS를 사용하는 경우에는 클라우드 벤더의 재량에 따르게 되므로 요구사항이 규정되기를 원하게 된다.
또한, 벤더에 C&A(Certification and Accreditation) 컨설턴트가 있고 벤더가 FISMA(Federal Information Security Management Act)를 준수한다고 하더라도 이것이 비밀 데이터가 적절하게 보호된다는 사실을 의미하지는 않는다는 점을 기억해야 한다. 정부 담당자라면 담당 임원이 납득할 수 있는 증거를 확보하기 위해 더욱 노력해야 한다.
벤더를 포함하여 모든 사람들은 감사와 로깅이 중요하다는 점을 알고 있다. 그러나 모든 사람이 감사와 로깅을 올바르게 수행하는 것은 아니다. 로그를 기록하는 시스템은 로그될 시스템과 같은 시스템에 있어서는 안 되며 대부분의 운영 체제에는 로그 기능이 있지만 그것만으로는 충분하지 않다. 원격 syslog와 실시간 로그 전송은 일부 상황에서만 사용되지 않고 거의 모드 상황에서 사용된다. 애플리케이션 이벤트, 데이터베이스 로그 및 보안 활동 추적은 해싱 및 보장된 메시지 전달 메커니즘과 같은 부인방지(non-repudiation) 기능을 사용하여 완전히 감사가 가능한 중앙화된 로그에 저장되어야 한다. 벤더의 자체 로그에 액세스할 수 있는 권한이 벤더에 있고 벤더가 이 로그를 수정할 수 있는 경우에는 벤더를 믿을 수 없다. 물론 로그에 액세스할 수 있는 권한이 벤더에 있어야 하지만 벤더가 로그를 수정할 수 있어서는 안 되며 로그 관리 시스템이 로그의 변조나 해킹 시도를 발견할 수 있어야 한다. 이벤트가 발생한 후에 포렌식 분석을 할 경우에는 로그가 증거를 구성하는 기본적인 자료가 되므로 로그는 신뢰할 수 있어야 하며 또한, 언제든지 사용 가능해야 한다.
정부 시스템은 특히 서비스 거부나 디페이싱 공격에 취약하며 이러한 공격의 목적은 단지 정부 기관, 정부 기관의 임무나 그 직원을 방해하는 데 있다. 네트워크 대역폭 포화라고도 하는 패킷 플러딩은 가장 일반적으로 발생하는 위험이다. 그리고 대부분의 클라우드 제공업체(특히 SaaS 제공업체)는 다른 누군가가 이러한 위험을 처리한다고 생각하기 때문에 벤더에서 이러한 위험을 명확하게 어떤 식으로 처리하는지 문의해야 한다. 또한, 봇넷(botnet)을 어떻게 식별하고 IaaS, PaaS나 SaaS 환경으로 침입할 가능성이 있는 악의적인 네트워크 트래픽을 어떻게 차단하는지 확인해야 한다. 벤더는 알고 있는 서명을 사용하여 네트워크 공격 패킷을 세심하게 조사하고 웹이나 애플리케이션 서버를 중지시킬 수 있는 대용량 데이터 패킷이 한꺼번에 전송되는 것을 자동으로 차단해야 한다.
정부의 IaaS, PaaS나 SaaS 요구사항에 IP 주소나 DNS를 통해 데이터 소스를 확인하는 기능이 포함되는 경우에는 클라우드 제공업체가 IP와 DNS 위조 및 ARP 플러딩을 방지할 수 있는지 확인하고 싶을 것이다. 또한, 패킷 변조, 다른 테넌트에 의한 개인 사설 서비스 정보 수집 및 특별한 보호가 필요한 구성 데이터나 암호화 키를 변조하는 행위를 방지하는 계약상의 의무가 벤더에게 있어야 한다.
이 기사를 통해 정부가 모든 유형의 IT 시스템을 사용하는 대규모 사용자라는 사실을 확인했다. 더욱 민첩해지고, 벤더의 목표와 임무를 더욱 신속하게 충족시키며 개발 위험을 줄이고 IT 시스템 실행과 관련된 비용과 전체 예산을 절약하기 위해 대부분의 정부 조직에서는 클라우드 솔루션을 구현하는 작업을 주시하고 있다. 비즈니스 면에서 클라우드는 엄청난 이점이 있으며 몇 가지 보안상의 혜택도 있다. 따라서 시간이 경과하게 되면 클라우드에 대한 이해도가 증대하고 클라우드를 더욱 효과적으로 사용하게 될 것이다. 현재는 클라우드가 새로운 기술인 관계로 정부 직원이 조심스러워하는 것도 당연하다. 클라우드 벤더는 물론이고 아무도 모든 보안 위험을 인식할 수는 없다. 그러나 그렇다고 해서 보안 문제를 진지하게 여기고 그들의 위협 모델을 잘 아는 벤더와 클라우드를 시험하는 것을 중지해서는 안 된다.
교육
- FISMA(Federal Information Security Management Act) 구현 프로젝트: 주요 보안 표준과 지침의 개발을 촉진하여 FISMA의 구현과 준수를 지원하는 방법을 배우자.
- Federal Information Processing Standards publication 140-2: 암호화 모듈의 보안 요구사항에 관해 자세히 배우자.
- Navigate the cloud computing labyrinth(Brett McLaughlin, developerWorks, 2009년 3월): 특정 애플리케이션 요구사항에 맞는 최상의 클라우드 컴퓨팅 플랫폼과 관련하여 현명한 결정을 하자.
- IBM 클라우드 컴퓨팅: IBM의 클라우드 컴퓨팅과 관련 비전을 자세히 배우자.
- 클라우드 컴퓨팅: 이 Wikipedia 기사를 읽어보고 SaaS, Iaas 및 PaaS에 관해 배우자.
- Cloud Computing with Amazon Web Services(Prabhakar Chaganti, developerWorks, 2008년 7월): Amazon Web Services 사용을 안내하는 단계별 안내서를 읽어보자.
- Cloud Computing Tutorial(Jens Nimis, SlideShare, 2009년 7월): 클라우드 컴퓨팅 환경을 소개하는 이 튜토리얼을 읽어보자.
- developerWorks Industries 영역: 특정 산업에 적합한 개발자용 최신 기술 자료를 모두 얻자.
- IBM developerWorks Cloud Computing Zone: 클라우드 컴퓨팅 관련 업데이트 자료를 찾아보자.
- 산업용 라이브러리: 기술 문서와 팁, 튜토리얼, 표준 및 IBM Redbooks는 developerWorks 산업용 라이브러리를 참고하자.
- My developerWorks: developerWorks와 관련된 경험을 개인화할 수 있다.
- developerWorks 기술 행사 및 웹 캐스트: 이러한 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다.
- Twitter의 developerWorks 페이지: 오늘 가입하여 developerWorks 트윗을 팔로우하자.
- developerWorks
podcasts: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
제품 및 기술 얻기
- IBM Smart Business Development and Test on the IBM Cloud: 클라우드 애플리케이션 개발을 시작하자.
- IBM 제품 평가판: IBM SQA Sandbox의 온라인 시험판을 다운로드하거나 살펴보고 DB2®,
Lotus®, Rational®, Tivoli® 및
WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
토론
- developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
Shahid N. Shah is an internationally recognized and influential healthcare IT thought leader who is known as "The Healthcare IT Guy" across the Internet. He is a consultant to various federal agencies on IT matters and winner of Federal Computer Week's coveted "Fed 100" award given to IT experts that have made a big impact in the government. Shahid has architected and built multiple clinical solutions over his almost 20-year career. He helped design and deploy the American Red Cross's electronic health record solution across thousands of sites; he's built two web-based EMRs now in use by hundreds of physicians; he's designed large groupware and collaboration sites in use by thousands; and, as an ex-CTO for a billion-dollar division of CardinalHealth, he helped design advanced clinical interfaces for medical devices and hospitals. Shahid also serves as a senior technology strategy advisor to NIH's SBIR/STTR program helping small businesses commercialize their healthcare applications.
목차
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그