パロアルトネットワークスは、数百社の顧客に対する業務に基づいて、Big Cloud 5を策定しました。これは網羅的なものではありませんが、適切な組織を整えることで、お客様のチームが包括的クラウド セキュリティ戦略を作成する際に役に立ちます。

図1：Big Cloud 5

状況を認識していないこと、または認識が不十分なことは、人的ミスに起因する災難の主な要因の1つと見なされています。– Nullmeyer、Stella、Montijo、Harden、2005

1.状況を認識してクラウドを詳細に監視する。

クラウドのセキュリティとコンプライアンスを達成しやすくするには、社内の開発者とビジネスチームが現在クラウドをどのように使っているのかを理解することから始めます。最初に調べる必要があるのはシャドーITによるクラウドの使用についてですが、ここは深く掘り下げる必要があります。80対20の法則に従うことで、最初に注目すべきクラウド プラットフォームを知ることができます。しかし、セキュリティ チームは、どのクラウド プラットフォームを使用しているかだけでなく、その内部で何が動作しているのかも理解する必要があります。ここで役に立つのがクラウド プロバイダAPIです。

クラウドを多くのオンプレミス環境と差別化する主要テクノロジの1つがAPIです。ここでは、クラウド環境内で行われていることについて常に状況を認識します。どのクラウド アプリを組織が使用しているかを理解するだけでなく、クラウド プロバイダAPIを利用してメタデータ レイヤーに及ぶ変化を常に追跡することを検討してください。

2.クラウドの最も重大な設定ミスを自動で阻止する防壁を設定する。

自社環境に決して存在してはならない設定（設定ミスまたはアンチパターン）とは何かを考えます。1つの例として、インターネットから直接トラフィックを受信するデータベースがあります。これは「最悪のプラクティス」であるにもかかわらず、Unit 42の脅威リサーチでは、クラウド環境の28%で実行されていることが示されています。初期リストを作成して、クラウド セキュリティ プログラムの成熟に合わせてこのリストを拡張します。ここで、重要な注意事項が2つあります。1つは、保護を自動化するときは、まず小規模な実験を行って、予期しない結果（サービス拒否を自ら招くなど）が発生しないことを確認することを強く推奨します。もう1つは、開発チームと緊密に連携することです。開発チームから同意を得ないで自動保護の導入を進めないでください。初日から開発チームと連携して、小さく始めて速やかに進めましょう。

3.標準を定めてから自動化に進む。

多くのチームが、セキュリティ標準を策定しないで、自動化の話をしています。時間をかけてセキュリティ標準の80%を自動化することが、適切な目標です。プログラムが標準に準拠すると、自動化を進めやすくなります。スタートアップ企業である場合を除いて、まったく自動化されていない状況から90日以内に完全な自動化を達成しようとは思わないでください。企業でこのプロセスが軌道に乗るまで、通常は少なくとも9ヶ月かかります。

4.コーディングするセキュリティ エンジニアをトレーニング/採用する。

従来の多くのデータセンターと異なり、パブリック クラウド環境ではAPIを使用してアクションを起こします。クラウドでリスク管理を成功させるには、セキュリティ チームがAPIを利用する必要があります。

組織の規模に応じて、現在すでに存在するスキルを評価することから始めます。PythonやRubyなどの言語でコーディングする方法を知っているチームメンバーがいるかどうかを確認します。いる場合は、そのチームメンバーに重点的に投資して、企業の自動化成熟度スケジュールに合わせて目標を設定します。チームにそのようなメンバーがいない場合は、いくつかの選択肢があります。コーディングを学習する意欲のある人および開発チームの中でこれまでセキュリティに興味を示していたメンバーを探します。トレーニングを中心にした目標を設定して、適切な体制を整えれば、開発者にセキュリティを教えることも、セキュリティ エンジニアにコーディングを教えることも、どちらも可能です。

組織にコーディングに強い人がいない場合、これまで多くの組織で経験を積んでいる短期コンサルタントに最適なプロジェクトかもしれません。チームが修正または使用する方法がわからないスクリプトを残してはいけません。このプロセスが軌道に乗れば、開発パイプラインにセキュリティを完全に組み込む作業を開始できます。

5.開発パイプラインにセキュリティを組み込む。

ここでは、組織がコードをクラウドへプッシュする方法について、誰が何をいつどこで実行するかをマッピングします。その後は、セキュリティ プロセスとツールの挿入ポイントとして最も影響が少ないポイントを特定することを目標にする必要があります。早い時期に開発チームから同意を得ることが重要です。

結論

これまでずっと開発チームの領域でしかなかったパブリック クラウドですが、「Big Cloud 5」に焦点を当てたクラウド セキュリティ戦略を構築することによって、あらゆる規模のセキュリティ組織がその恩恵を受けられるようになります。小さく始めて速やかに進めましょう。

在與數百位客戶合作的經驗基礎上，我們開發出 5 大雲端安全策略。雖然並非盡善盡美，但如果使用得當，它能夠幫助您的團隊擬定全面的雲端安全策略。

圖 1：5 大雲端安全策略

對環境缺乏足夠的認識，被認為是因人為錯誤導致事故發生的主要原因之一。– Nullmeyer，Stella、Montijo 和 Harden，2005 年

1.瞭解雲端環境，取得深入的可視性。

簡化雲端安全性與合規性工作的第一步，是瞭解開發人員和業務團隊目前如何使用雲端。首先需要瞭解影子 IT 對雲端的使用情況，但還不能僅僅滿足於此。遵循 80/20 法則，您的團隊可以確定需要首先關注的雲端平台。但是，安全團隊不僅要瞭解正在使用哪些雲端平台，也要瞭解在其中執行的內容。這就是雲端供應商的 API 發揮作用之處。

API 是使得雲端與大多數內部部署環境不同的關鍵技術之一。您需要始終掌握雲端環境中發生的情況，這不僅需要瞭解貴公司正在使用的雲端應用，也要運用雲端供應商的 API 持續追蹤直至中繼數據層的所有變化。

2.設定防護措施，自動防禦最嚴重的雲端錯誤設定。

問問自己，哪些設定 (錯誤設定或反面模式) 在我們的環境中不應該存在？例如，數據庫從網際網路直接獲得流量。這是「最不理想的做法」，但 Unit 42 的威脅研究指出，有 28% 的雲端環境中存在這種情況。隨著雲端安全計劃日趨成熟，有必要擬定初步的安全措施並逐步進行擴展。在此提出兩項重要注意事項：建立自動化防護之前，強烈建議首先進行小規模的試驗，確保不會產生意料之外的結果 (例如，自我造成的拒絕服務)。與開發團隊密切合作。如果沒有開發團隊的支援，請勿嘗試實作自動化防護。從一開始就與開發團隊合作，從基礎開始，為未來的成功奠定基礎。

3.標準是自動化的前提條件。

許多團隊在沒有建立標準的情況下就開始談論自動化。妥善的做法是隨時間推移，逐漸將 80% 的目標自動化。隨著在計劃中完成標準訂定，自動化的工作自然水到渠成。除非是新創公司，否則不要期待在 90 天內即可完成從無自動化到全自動化的轉換。企業通常需要至少九個月才能完成這個過程。

4.培訓和聘用編寫程式碼的安全工程師。

與大多數傳統的數據中心不同，公有雲環境是由 API 驅動。在雲端中進行成功的風險管理需要安全團隊運用 API。

根據貴公司的規模，先評估目前已有的技能。是否已經有團隊成員熟悉如何編寫 Python 或 Ruby 之類的程式碼？如果有，請大力投資這些團隊成員，根據建立成熟自動化防護的時間表調整自己的目標。團隊裡面沒有這樣的人？那麼您有幾個選擇。確認是否有人想要學習這些技術，並透過調查尋找開發團隊中對於安全技術感興趣的成員。如果訓練的目標一致，而且配置有妥善的資源，那麼可以培訓開發人員進行安全工作，也可以培訓安全工程師編寫程式碼。

如果貴公司在編寫程式碼方面並不擅長，一個不錯的選擇是聘用曾與許多組織有過合作經驗的短期顧問。您不會希望團隊不知道如何修改或使用指令碼。完成這個過程後，就可以在開發渠道中完全嵌入安全性。

5.在開發渠道中嵌入安全性。

在確定如何將程式碼推送到雲端時，需要確定相關人員、內容、時間和位置。完成這一點後，您的目標應該是為安全流程和工具找到破壞性最小的進入點。獲得開發團隊的早期支援極為重要。

結論

透過建構專注於「5 大雲端安全策略」的雲端安全策略，各種規模的安全組織都將享受公有雲所帶來的優勢，而長期以來只有開發團隊從這些優勢中受益。從基礎開始，為未來的成功奠定基礎。

Op basis van het werk dat wij hebben verricht voor onze honderden klanten, hebben we The 5 Big Cloud ontwikkeld. Dit is natuurlijk lang niet het enige dat u moet doen, maar met deze vijf aanbevelingen bent u al een heel eind op weg naar een holistische strategie voor cloudbeveiliging.

Afbeelding 1: The 5 Big Cloud

Het gebrek aan omgevingsbewustzijn wordt gezien als een van de belangrijkste factoren voor ongelukken die te wijten zijn aan menselijke fouten. – Nullmeyer, Stella, Montijo & Harden, 2005

1. Zorg voor inzicht en uitstekende zichtbaarheid van de cloud.

De eerste stap op weg naar een goede cloudbeveiliging en compliance is begrijpen hoe uw ontwikkelaars en interne gebruikers de cloud nu gebruiken. Daarbij is het gebruik van de cloud via schaduw-IT belangrijk, maar u hebt nog veel meer informatie nodig. Aan de hand van de 80/20-regel kunt u bepalen op welk cloudplatform u zich eerst moet richten. Uw beveiligingsmensen moeten echter niet alleen weten welke cloudplatforms er worden gebruikt, maar ook wat daarop draait. En daarbij zijn de API's van de cloudprovider heel belangrijk.

API's zijn de essentiële technologieën die de cloud anders maken dan de meeste on-premises omgevingen. Het gaat erom dat u zich goed bewust bent van wat er op dit moment in uw cloudomgevingen gebeurt. Probeer niet alleen inzicht te krijgen in welke cloudapps er binnen uw organisatie worden gebruikt, maar benut de API's van de cloudprovider om doorlopend op de hoogte te zijn van wijzigingen in de metadata-laag.

2. Breng barrières aan voor het automatisch voorkomen van de ernstigste cloudconfiguratiefouten.

Bedenk welke configuraties (misconfiguraties en antipatronen) nooit mogen bestaan in uw omgeving; zoals een database die rechtstreeks gegevensverkeer van internet ontvangt. Want ondanks dat dit wordt gezien als een zogeheten 'worst practice', blijkt uit onderzoek van Unit 42 dat deze situatie in 28% van de cloudomgevingen voorkomt. Stel een initiële lijst op en breid die uit naarmate uw cloudbeveiliging volwassener wordt. Houd rekening met twee belangrijke zaken: wanneer u beschermingsmiddelen automatiseert, is het verstandig om klein te beginnen en ze goed te testen, zodat er geen onbedoelde neveneffecten optreden (zoals een door u zelf veroorzaakte denial of service). Werk nauw samen met uw ontwikkelaars. Implementeer geen geautomatiseerde beveiligingsmiddelen zonder de betrokkenheid van uw ontwikkelteams. Werk vanaf het begin met ze samen, begin klein en schaal snel op.

3. Beleid is de voorloper van automatisering.

Vaak wordt er al gesproken over automatisering zonder dat er een beveiligingsbeleid van kracht is. Een goede doelstelling is om in de loop der tijd 80% van de beleidsregels te automatiseren. Wanneer uw beveiligingsinspanningen al zijn gebaseerd op beleidsregels, wordt het automatiseren ervan een stuk eenvoudiger. Maar verwacht niet dat u binnen 90 dagen van geen automatisering naar volledige automatisering kunt gaan, tenzij u een start-up bent. Bij een bedrijf van enige omvang kost het al snel ten minste negen maanden voordat dit proces op orde is.

4. Train en werf beveiligingsengineers die code kunnen schrijven.

In tegenstelling tot de meeste traditionele datacenters draaien publieke-cloudomgevingen op API's. Voor een goed risicobeheer in de cloud moeten uw beveiligingsmensen dan ook gebruikmaken van die API's.

Afhankelijk van de omvang van uw organisatie begint u met het evalueren van de aanwezige vaardigheden. Zijn er misschien al teamleden die Python of Ruby beheersen? Zo ja, investeer dan flink in die mensen en stem hun werkzaamheden af op uw automatiseringsplanning. Als er niemand is die dergelijke code kan schrijven, hebt u diverse opties. Bepaal of er mensen zijn die het willen leren, en identificeer degenen in het ontwikkelteam die geïnteresseerd zijn in beveiliging. Beide vaardigheden zijn te leren; ontwikkelaars kunnen worden opgeleid op het gebied van beveiliging en beveiligingsengineers kunnen code leren schrijven. Let er wel op dat de opleidingsdoelstellingen goed op elkaar zijn afgestemd en er voldoende middelen en mogelijkheden worden geboden.

Als de vaardigheden op het gebied van code schrijven beperkt zijn binnen uw organisatie, kan dit een mooi project zijn voor een tijdelijke consultant die vergelijkbare werkzaamheden al heeft verricht bij andere organisaties. U wilt niet blijven zitten met scripts die uw mensen niet kunnen gebruiken of aanpassen. Zodra dit proces in gang is gezet, bent u klaar om beveiliging een kernonderdeel te maken van uw complete ontwikkelingspijplijn.

5. Maak beveiliging een kernonderdeel van de ontwikkelingspijplijn.

Hierbij gaat het erom dat u tot in detail weet hoe uw organisatie code naar de cloud overbrengt. Zodra dat bekend is, zoekt u naar de plaats waar beveiligingsprocessen en -hulpmiddelen zo onmerkbaar mogelijk kunnen worden geïmplementeerd. Ook hierbij is vroege betrokkenheid van de ontwikkelteams cruciaal.

Conclusie

Met een cloudstrategie die is gefocust op The 5 Big Cloud kunnen zowel grote als kleine beveiligingsafdelingen profiteren van de voordelen van publieke clouds, waardoor die niet langer zijn voorbehouden aan ontwikkelaars. Klein beginnen, snel opschalen.

당사는 수많은 클라이언트와 진행했던 작업을 토대로, 빅 클라우드 5라는 전략을 개발했습니다. 비록 완벽하지는 않겠지만, 이 내용을 적절하게 활용하면 담당 팀이 종합적인 클라우드 보안 전략을 구축하는 데 유용할 것입니다.

그림 1: 빅 클라우드 5

상황에 대한 정보가 없거나 부족한 것은 사람의 실수로 인해 발생하는 사고의 주요 요인 중 하나로 간주된다. – Nullmeyer, Stella, Montijo & Harden, 2005

1. 상황 정보 및 심층적인 클라우드 가시성을 확보하십시오.

더욱 손쉬운 클라우드 보안 및 규정 준수를 실현하기 위한 첫 번째 단계는 개발자 팀과 비즈니스 팀이 현재 클라우드를 어떤 방식으로 사용하고 있는지 파악하는 것입니다. 섀도 IT를 통한 클라우드 사용 현황은 필수적인 세부 정보의 첫 번째 단계지만, 더욱 심층적인 접근이 필요합니다. 80/20 규칙을 따르면 어떤 클라우드 플랫폼에 가장 먼저 중점을 두어야 할지 알 수 있습니다. 그러나 보안 팀은 어떤 클라우드 플랫폼이 사용 중인지 파악하는 것뿐만 아니라, 그 내부에서 어떤 것이 실행되고 있는지도 파악해야 합니다. 클라우드 공급자 API가 바로 이를 해결하는 역할을 합니다.

API는 대부분의 온프레미스 환경과 클라우드를 차별화하는 핵심 기술 중 하나입니다. 이는 클라우드 환경에서 어떤 일이 일어나고 있는지에 대한 상황 정보를 입수하고 유지하는 기술입니다. 귀사에서 어떤 클라우드 앱을 사용 중인지 파악하는 것뿐만 아니라, 클라우드 공급자 PAI를 활용하여 메타데이터 레이어 수준까지 변경 사항을 지속적으로 추적할 수 있게 된다면 어떨지 생각해 보십시오.

2. 가장 심각한 클라우드 구성 오류를 자동으로 방지하는 안전장치를 설치하십시오.

우리 회사의 환경에 절대로 존재해서는 안 되는 구성(구성 오류 또는 안티패턴)은 무엇인지 스스로에게 질문해 보십시오. 그 예로 인터넷에서 직접 트래픽을 수신하는 데이터베이스를 들 수 있을 겁니다. 이는 "가장 최악의 경우"임에도 불구하고, Unit 42의 위협 조사에 따르면 클라우드 환경에서 이러한 일이 발생하는 확률은 28%에 달하는 것으로 나타났습니다. 클라우드 보안 프로그램이 성숙해가는 과정 동안 초기 목록을 작성하고 이를 확대해 나가십시오. 두 가지 중요한 주의 사항이 있습니다. 보호 기능을 자동화하는 모든 경우, 의도치 않은 결과(예: DOS(서비스 거부)를 자초하는 경우)를 방지하려면 반드시 작은 실험부터 시작하는 것이 바람직합니다. 개발 팀과 긴밀한 협업을 수행하십시오. 그리고 개발 팀의 승인 없이는 자동화된 보호 기능을 설치하지 마십시오. 첫째 날부터 개발 팀과 긴밀한 협업을 수행하고, 작은 단계부터 시작하여 신속하게 규모를 늘리십시오.

3. 표준은 자동화를 위한 전제 조건입니다.

대다수의 팀이 보안 표준을 정해두지 않은 상태에서 자동화에 대한 담론을 벌이곤 합니다. 바람직한 목표는 시간의 추이에 따라 80% 이상의 자동화를 달성하도록 설정하는 것입니다. 프로그램이 표준을 토대로 설정되면 자동화 작업은 더욱 간단해집니다. 스타트업 업체가 아닌 이상, 아무것도 자동화되지 않은 상태에서 90일 이내에 전면적인 자동화를 끝내겠다는 기대는 하지 마십시오. 이 프로세스는 엔터프라이즈 조직의 경우 통상적으로 제 속도를 내기까지 최소 9개월이 걸리는 작업입니다.

4. 코딩을 할 줄 아는 보안 엔지니어를 교육하고 채용하십시오.

대다수의 기존 데이터센터와 달리, 퍼블릭 클라우드 환경은 API를 기반으로 움직입니다. 클라우드에서 위험을 올바르게 관리하려면 API를 활용하는 보안 팀이 있어야 합니다.

조직의 규모에 따라, 현재 이미 보유하고 있는 기술을 평가하는 단계부터 시작하십시오. 귀사는 Python 또는 Ruby 같은 코딩 작업을 할 수 있는 팀원을 이미 보유하고 있습니까? 그렇다면 이러한 팀원들에게 집중적인 투자를 하고, 자동화 성숙 기간에 맞춰 목표를 조정하십시오. 팀에 이러한 직원이 아직 없습니까? 그렇다면 몇 가지 옵션을 고려할 수 있습니다. 이러한 기술을 배우고 싶어 하는 직원을 물색하고, 개발 팀에서 보안 분야에 관심을 표한 팀원이 누구인지 조사하십시오. 교육에 대한 목표가 잘 조율되어 있고 리소스를 올바르게 활용할 경우, 개발자를 위한 보안 교육 및 보안 엔지니어를 위한 코딩 교육 두 가지를 모두 적절하게 교육할 수 있습니다.

귀사에 코딩 실력이 뛰어난 직원이 없을 경우, 일전에 수많은 조직에서 해당 업무를 진행한 경험이 있는 단기 컨설턴트에게는 이러한 작업이 큰 프로젝트가 될 수 있습니다. 스크립트를 수정하거나 사용할 줄 모르는 팀원들에게 스크립트만 던져주는 상황은 원치 않을 것입니다. 이러한 프로세스를 진행 중인 상태라면, 개발 파이프라인에 보안을 완전히 포함할 준비를 갖추게 된 것입니다.

5. 개발 파이프라인에 보안을 포함하십시오.

이는 누가, 무엇을, 언제, 어디서라는 원칙에 따라 귀사가 클라우드에 코드를 짜 넣는 방식을 계획하는 일입니다. 이 작업이 완료되면, 다음 목표는 보안 프로세스 및 도구에 가장 방해가 되지 않는 삽입 지점을 찾는 것입니다. 조기에 개발 팀의 승인을 받는 것이 매우 중요합니다.

결론

모든 규모의 보안 조직은 "빅 클라우드 5"에 중점을 둔 클라우드 보안 전략을 구축하여 그동안 개발 팀의 영역에만 머물러 있었던 퍼블릭 클라우드의 이점을 활용할 수 있습니다. 작은 단계부터 시작하고, 신속하게 규모를 늘리십시오.

The 5 Big Cloud Security Strategy nasce dall'esperienza acquisita con centinaia di clienti. Benché non sia concepito come sistema esaustivo, se dotato di adeguate risorse, può aiutare il tuo team a costruire una strategia olistica di sicurezza cloud.

Figura 1: The 5 Big Cloud Security Strategy

Una mancata o carente consapevolezza situazionale è uno dei fattori primari degli incidenti attribuiti a errore umano. – Nullmeyer, Stella, Montijo & Harden, 2005

1. Migliorare la consapevolezza e la visibilità sul cloud.

Il primo passo per semplificare la sicurezza e la conformità del cloud è capire come viene usato il cloud dagli sviluppatori e dai team aziendali nel momento presente. L'utilizzo del cloud tramite shadow IT è il primo livello di dettaglio richiesto, ma è necessario approfondire ulteriormente. Seguendo la regola 80/20, il tuo team saprà su quale piattaforma cloud dovrà prima concentrarsi. I team della sicurezza devono capire non solo quali piattaforme cloud sono al momento utilizzate, ma anche cosa viene eseguito su di esse. Diventano indispensabili, a questo proposito, le API del fornitore cloud.

Le API sono una delle principali tecnologie che differenziano il cloud dalla maggior parte degli ambienti on-premise. Consentono di ottenere e mantenere consapevolezza su ciò che accade nei tuoi ambienti cloud. Non solo si possono identificare le applicazioni cloud utilizzate dalla tua organizzazione, ma sfruttando le API del fornitore cloud si possono tracciare costantemente i cambiamenti sul layer dei metadati.

2. Adotta misure per prevenire automaticamente i più gravi errori di configurazione del cloud.

Pensa a quali configurazioni (erronee o antipattern) non dovrebbero mai esistere nel tuo ambiente. Ad esempio, un database che riceve traffico direttamente da Internet. Malgrado sia una “cattiva prassi”, la ricerca sulle minacce di Unit 42 ha dimostrato che è adottata nel 28% degli ambienti cloud. Compila una lista iniziale e continua ad espanderla di pari passo con il procedere del tuo programma di sicurezza cloud. Due avvertenze importanti: ogni volta che si automatizzano le protezioni, è consigliabile partire con piccoli esperimenti per scongiurare l'eventualità di conseguenze inattese (ad es. un denial of service autoinflitto). Collabora strettamente con i team di sviluppo. Non cercare di implementare protezioni automatiche senza avere l'approvazione dei team di sviluppo. Collabora con i team di sviluppo dal primo giorno, inizia in piccolo per poi crescere rapidamente.

3. Gli standard sono i precursori dell'automazione.

Molti team parlano di automazione senza avere ancora implementato uno standard di sicurezza. Un obiettivo ambizioso è automatizzare nel tempo l'80% di questi. Se il tuo programma si basa sugli standard, la parte relativa all'automazione diventa più immediata. Non aspettarti di passare da automazione zero ad automazione totale in 90 giorni, a meno che tu non abbia una startup. Nelle grandi organizzazioni, il processo richiede almeno nove mesi per raggiungere l'obiettivo.

4. Assumi e addestra ingegneri della sicurezza che scrivono codice.

A differenza dei tradizionali data center, gli ambienti di cloud pubblico sono incentrati sulle API. Un'adeguata gestione del rischio nel cloud richiede ai team della sicurezza di sfruttare le API.

A seconda delle dimensioni dell'azienda, inizia con una valutazione delle competenze che già esistono all'interno. Hai già membri del team che sanno scrivere codice in Python o Ruby? Se sì, investi fortemente su queste persone e imposta gli obiettivi in base al grado di maturità dell'automazione. Non hai persone competenti nel team? Allora hai diverse opzioni. Cerca persone che vogliano imparare e identifica all'interno del team di sviluppo i membri che hanno interesse nella sicurezza. Se gli obiettivi sono chiari e le risorse adeguate, la formazione è possibile in entrambe le direzioni: sicurezza per gli sviluppatori e scrittura di codice per gli ingegneri della sicurezza.

Se la tua azienda ha scarse competenze di programmazione, il progetto può essere assegnato a un consulente a breve termine che ha già esperienze simili in altre organizzazioni. L'importante è non restare con pagine di codice che i tuoi team non sanno modificare o utilizzare. Una volta avviato il processo, sarai pronto a integrare completamente la sicurezza nella tua pipeline di sviluppo.

5. Integrare la sicurezza nella pipeline di sviluppo.

Si tratta di mappare ogni aspetto - chi, cosa, quando e dove - di come la tua organizzazione immette codice nel cloud. Conclusa l'operazione, l'obiettivo è individuare i punti di inserimento meno problematici per i processi e gli strumenti di sicurezza. È essenziale ottenere l'approvazione preliminare dei team di sviluppo.

Conclusione

Impostando una strategia di sicurezza cloud basata su “The 5 Big Cloud Security Strategy,” le organizzazioni di sicurezza di tutte le dimensioni potranno godere dei benefici del cloud pubblico, di solito appannaggio esclusivo dei team di sviluppo. Comincia in piccolo, e cresci rapidamente.

Aujourd’hui, pleins feux sur « The 5 Big Cloud ». Inspirée de notre collaboration avec des centaines de clients, cette approche ne prétend nullement être exhaustive, mais elle permettra à votre équipe de tracer les grandes lignes de sa stratégie de sécurité du cloud.

Figure 1 : « The 5 Big Cloud »

Les accidents imputables à une erreur humaine sont très souvent dus à une mauvaise lecture de la situation. – Nullmeyer, Stella, Montijo et Harden, 2005

1. Élargissez et approfondissez votre visibilité du cloud.

Avant toute chose, vous devez bien comprendre comment vos développeurs et vos équipes métiers utilisent le cloud aujourd’hui. Ce bilan initial est le premier pas vers une gestion simplifiée de la conformité et de la sécurité du cloud. Priorité numéro un : identifier tous les cas d'usage du cloud sortant du champ de contrôle de la fonction informatique (Shadow IT). Ensuite, il faut creuser. La règle du 80-20 vous permettra d’identifier la plateforme cloud à laquelle vous devez vous attaquer en premier. Mais attention à ne pas vous limiter à de simples facteurs quantitatifs : si les équipes de sécurité doivent connaître le quoi (quelles plateformes cloud sont utilisées), elles doivent aussi comprendre le comment (ce qui s'y exécute). C’est là que les API des CSP (Cloud Service Providers) entrent en jeu.

Les API sont l’un des principaux facteurs de différenciation du cloud par rapport aux déploiements sur site. Grâce à elles, vous avez une lecture beaucoup plus précise de la situation dans vos environnements cloud : non seulement vous savez quelles applications cloud sont utilisées, mais vous assurez aussi un suivi du moindre changement effectué jusque dans la couche de métadonnées.

2. Placez des garde-fous automatiques pour prévenir les erreurs de configuration.

Commencez par répondre à la question suivante : quelles sont les configurations à bannir à tout prix ? Prenons un cas d’école : une base de données ne devrait jamais être directement accessible depuis Internet. Cela tombe sous le sens, et pourtant, selon nos équipes de recherche de l'Unit 42, un accès direct a pu être observé dans 28 % des environnements cloud. Pour parer à ce type de danger, dressez votre liste initiale des pratiques interdites, puis enrichissez-la à mesure que votre programme de sécurité du cloud évolue. Deux précautions d'usage : chaque fois qu'une mesure de sécurité est automatisée, commencez petit et guettez d’éventuelles conséquences imprévues (du genre déni de service auto-imposé). Parallèlement, travaillez au contact direct des équipes de développement. Inutile d’implémenter des mesures de protection automatisées sans avoir obtenu leur feu vert. En résumé, impliquez les développeurs dès le départ et ne cherchez pas à aller trop vite. Une fois ces conditions remplies, vous pourrez accélérer le déploiement.

3. N’oubliez pas que l’automatisation est d'abord une question de standards.

On ne compte plus les équipes de sécurité qui parlent d’automatisation avant même d'avoir établi des standards de sécurité. Il est bon de se fixer un objectif ambitieux, par exemple atteindre 80 % d’automatisation à terme. Mais mettez-vous d'abord d'accord sur des standards, et l’automatisation viendra d'elle-même. À moins d'être une start-up, ne vous attendez pas à automatiser tous vos processus en trois mois : généralement, il faut au moins neuf mois avant qu’une grande structure trouve son rythme.

4. Formez et embauchez des ingénieurs sécurité qui savent coder.

Contrairement à la plupart des data centers traditionnels, les clouds publics reposent sur des API. C'est donc en toute logique qu'ils constituent la clé de voûte d'une gestion des risques dans le cloud.

Comment procéder ? Selon la taille de votre organisation, commencez par établir un bilan des compétences à votre disposition. Certains de vos spécialistes sécurité maîtrisent-ils des langages comme Python et Ruby ? Si oui, exploitez ces compétences et alignez vos objectifs d’automatisation en conséquence. Si non, plusieurs options s’offrent à vous. Vous pouvez donner leur chance à ceux qui ont envie d’apprendre et aux membres de votre équipe de développement qui s’intéressent à la sécurité. Proposez aux développeurs de se former à la sécurité et aux ingénieurs sécurité de découvrir les joies du code. Attention cependant à bien y consacrer les ressources nécessaires et à harmoniser les objectifs pédagogiques de chaque groupe.

Pas beaucoup de pros du code dans votre entreprise ? N'hésitez pas à faire appel à un consultant externe chevronné pour une mission de courte durée. Vous ne voudriez surtout pas vous retrouver avec des scripts dont votre équipe ne saurait que faire. Une fois que vous aurez bien maîtrisé le processus, vous aurez toutes les cartes en main pour intégrer parfaitement la sécurité dans vos projets de développement.

5. Intégrez la sécurité dans vos projets de développement.

Qui, quoi, quand, comment et où ? Telles sont les questions essentielles à vous poser pour assurer la traçabilité du code déployé dans le cloud. Localisez ensuite les points d’entrée les moins perturbateurs pour vos processus et outils de sécurité. Là encore, mettez toutes les chances de votre côté en obtenant d'emblée l’adhésion des équipes de développement.

Conclusion

Quelle que soit leur taille, les équipes de sécurité ont tout intérêt à s’inspirer de l’approche « The 5 Big Cloud » pour élaborer leur stratégie de sécurité dans le cloud public. Elles profiteront ainsi d'avantages qui étaient autrefois l'apanage des seules équipes de développement. Commencez petit, mais voyez grand.

Basándonos en nuestro trabajo con cientos de clientes, desarrollamos la estrategia de seguridad «The 5 Big Cloud». Sin pretensiones de ser exhaustiva, con los recursos adecuados, su equipo podrá formular una estrategia de seguridad en la nube integral.

Figura 1: Estrategia de seguridad «The 5 Big Cloud»

Un conocimiento de la situación insuficiente o inadecuado es uno de los factores principales en accidentes atribuidos al error humano. – Nullmeyer, Stella, Montijo y Harden (2005).

1. Conozca la situación de su organización y procúrese una visibilidad profunda de la nube.

El primer paso para facilitar la seguridad y el cumplimiento normativo en la nube consiste en comprender cómo utilizan la nube hoy sus desarrolladores y equipos. Para ello, empiece por identificar los usos de la nube de los que el equipo de TI no tiene constancia, pero no se quede ahí. Seguir la regla del 80/20 permitirá a su equipo saber en qué plataforma de nube centrarse primero. Sin embargo, los equipos de seguridad no solo deben entender qué plataformas de nube se están usando, sino también qué es lo que se ejecuta dentro de ellas. Aquí es donde entran en acción las API de los proveedores de nube.

Las API son una de las tecnologías clave que diferencian a la nube de la mayoría de entornos locales. Se trata de saber en todo momento qué está pasando en sus entornos de nube. EL objetivo no solo es entender qué aplicaciones de nube se están usando en su organización; también debe utilizar las API de su proveedor de nube para tener constancia de los cambios que se producen en la capa de los metadatos en todo momento.

2. Instale barreras de protección para evitar los fallos de configuración de la nube más graves de manera automática.

Pregúntese qué configuraciones (ya sea porque sean erróneas o porque contengan antipatrones) no deberían existir nunca en su entorno, como por ejemplo una base de datos que reciba tráfico directo de Internet. Pese a ser una práctica desaconsejada, el equipo de investigación de amenazas Unit 42 ha demostrado que esto sucede en el 28 % de los entornos de nube. Escriba una lista inicial y vaya completándola conforme vaya madurando su programa de seguridad en la nube. Dos advertencias importantes: siempre que se automatiza un mecanismo de protección, se recomienda encarecidamente empezar con experimentos pequeños para minimizar las consecuencias no deseadas (por ejemplo, una denegación de servicio autoinfligida). Colabore codo con codo con sus equipos de desarrollo y renuncie a instalar mecanismos de protección automatizados sin ganarse previamente su compromiso y apoyo. Debe trabajar con ellos desde el primer día. Empiece poco a poco, sin prisa pero sin pausa.

3. Los estándares son los precursores de la automatización.

Muchos equipos hablan de la automatización sin tener ningún estándar de seguridad en vigor. Un objetivo razonable es alcanzar una automatización del 80 %. Una vez que el programa esté asentado sobre una base de estándares, la automatización vendrá prácticamente sola. En lo que a la automatización se refiere, no aspire a pasar de cero a cien en 90 días, a menos que sea una empresa pequeña que acaba de empezar. La mayoría de las organizaciones tarda en completar este proceso como mínimo unos nueve meses.

4. Dé formación a su personal y contrate ingenieros de seguridad que sepan programar.

A diferencia de la mayoría de los centros de datos tradicionales, los entornos de nube pública están basados en API. Una gestión adecuada del riesgo en la nube pasa por que los equipos de seguridad sepan utilizar las API.

En función del tamaño de su organización, empiece por evaluar las competencias que ya tiene. ¿Hay algún miembro del equipo que ya sepa programar en lenguajes como Python o Ruby? Si es así, invierta muchos recursos en estos miembros del equipo y trate de alinear sus objetivos con el calendario de la automatización. ¿Aún no tiene a nadie? Hay varias opciones. Busque en su plantilla a aquellas personas que quieran aprender e identifique a los miembros de su equipo de desarrollo que hayan mostrado interés por la seguridad. Se les puede formar (en seguridad a los desarrolladores y en programación a los ingenieros de seguridad), siempre y cuando los objetivos de formación estén bien formulados y dotados de recursos.

Si la programación no es uno de los puntos fuertes de su organización, este proyecto puede ser un buen candidato para asignárselo a un consultor externo temporal que lo haya hecho ya para muchas otras organizaciones en el pasado. No le servirá de mucho quedarse con scripts que sus equipos no sepan modificar ni usar. Cuando ya tenga este proceso encarrilado, tendrá todo lo necesario para integrar la seguridad en su proyecto de desarrollo.

5. Integre la seguridad en su proyecto de desarrollo.

Este elemento trata de responder al quién, qué, cuándo y dónde de cómo envía el código a la nube su organización. Hecho esto, su objetivo debería ser localizar los puntos de inserción menos disruptivos para los procesos y las herramientas de seguridad. Cuanto antes consiga el apoyo y el compromiso de sus equipos de desarrollo, mejor.

Conclusión

Diseñar una estrategia de seguridad en la nube que gire en torno a «The 5 Big Cloud» permite a las organizaciones de seguridad de cualquier tamaño cosechar los frutos de la nube pública; frutos que antes solo estaban al alcance de unos pocos equipos de desarrollo. Y recuerde: empiece poco a poco. Sin prisa, pero sin pausa.

Wir haben unsere Erfahrungen mit Hunderten von Kunden ausgewertet und die Sicherheitsstrategie „5 Big Cloud“ entwickelt. Sie deckt zwar nicht jedes mögliche Szenario ab, kann bei der Entwicklung einer holistischen Sicherheitsstrategie für die Cloud aber sehr nützlich sein – vorausgesetzt, dass dem verantwortlichen Team die erforderlichen Ressourcen zur Verfügung stehen.

Abbildung 1: Die „5 Big Cloud“

Eine der wichtigsten Ursachen für Unfälle, die auf menschliches Versagen zurückzuführen sind, ist das Nichterkennen bzw. die falsche Einschätzung einer Gefahrensituation. – Nullmeyer, Stella, Montijo & Harden, 2005

1. Verschaffen Sie sich ein umfassendes, detailliertes Bild der Cloud-Nutzung.

Als ersten Schritt zu einfacherer Cloud-Sicherheit und Compliance sollten Sie sich ein umfassendes Bild der aktuellen Cloud-Nutzung Ihrer Entwickler und der Teams in den Geschäftsbereichen machen. Dabei ist es unter anderem wichtig zu wissen, ob über Schatten-IT auf die Cloud zugegriffen wird. Falls ja, müssen Sie sich genauere Informationen über diese Zugriffe verschaffen. Empfehlen Sie Ihrem Team, das auch als „80:20-Regel“ bekannte Pareto-Prinzip zu nutzen, um zu entscheiden, welche Cloud-Plattform(en) zuerst untersucht werden sollte(n). Auch hier reicht es nicht aus, herauszufinden, welche Cloud-Plattformen genutzt werden. Ihre Sicherheitsteams sollten auch ermitteln, was auf diesen Plattformen ausgeführt wird. Dabei können die von den Cloud-Anbietern bereitgestellten APIs sehr nützlich sein.

APIs sind eine der Schlüsseltechnologien, bei denen sich Clouds von den meisten On-Premises-Umgebungen unterscheiden. Nutzen Sie sie, um sich ein genaues Bild der Cloud-Nutzung in Ihrem Unternehmen zu machen. Geben Sie sich nicht mit einer Liste der in Ihrem Unternehmen genutzten Cloud-Apps zufrieden. Nutzen Sie die APIs der Cloud-Anbieter, um sämtliche Änderungen bis auf die Metadaten-Ebene zu verfolgen.

2. Implementieren Sie Kontrollen, um die gefährlichsten Fehlkonfigurationen von Cloud-Umgebungen automatisch zu verhindern.

Fragen Sie sich, welche Konfigurationen (Fehlkonfigurationen oder fehlerhafte Muster) in Ihrer Umgebung nie vorkommen sollten. Ein Beispiel hierfür ist eine Datenbank, in die direkt aus dem Internet Befehle eingegeben werden können. Das ist eine der gefährlichsten Sicherheitslücken überhaupt, aber diese Konfiguration wurde von Unit 42 in 28 % der untersuchten Cloud-Umgebungen gefunden. Erstellen Sie gleich zu Anfang eine Liste unerwünschter Konfigurationen und erweitern Sie diese im Verlauf der Zeit, wenn Sie Ihr Sicherheitsprogramm stärken. Zwei wichtige Hinweise: Wenn Sie diese Kontrollen automatisieren, würde ich Ihnen dringend raten, das zuerst in einer kleinen Testumgebung zu tun. So können Sie vermeiden, dass unbeabsichtigte Nebenwirkungen zu einem schwerwiegenden, selbst verursachten Denial-of-Service-Vorfall führen. Und zweitens: Arbeiten Sie eng mit Ihren Entwicklerteams zusammen. Versuchen Sie nicht, automatische Kontrollen ohne vorherige Absprache mit den Entwicklern zu implementieren. Arbeiten Sie von Anfang an mit ihnen zusammen, fangen Sie klein an und nehmen Sie dann schnell Fahrt auf.

3. Standards sind die Vorläufer der Automatisierung.

In vielen Teams wird über die Automatisierung diskutiert, obwohl es noch gar keine Sicherheitsstandards gibt. Ein gutes Ziel ist, langfristig 80 % der standardisierten Prozesse zu automatisieren. Je mehr Sie die Prozesse in Ihrem Sicherheitsprogramm standardisieren, desto einfacher lassen sie sich automatisieren. Lassen Sie sich nicht weismachen, dass der Übergang von einem vollständig manuellen zu einem völlig automatisierten Sicherheitsbetrieb in 90 Tagen abgeschlossen sein kann. Wenn Ihr Unternehmen kein Startup ist, ist das äußerst unwahrscheinlich. In etablierten Großkonzernen nimmt die Automatisierung in der Regel mindestens neun Monate in Anspruch.

4. Ihre Sicherheitstechniker sollten programmieren können.

Anders als in den meisten herkömmlichen Rechenzentren spielen APIs in Public-Cloud-Umgebungen eine wichtige Rolle. Für ein erfolgreiches Risikomanagement muss Ihr Sicherheitsteam beispielsweise unbedingt die APIs des Cloud-Anbieters nutzen.

Je nachdem, wie groß Ihr Unternehmen ist, kann es sich lohnen, mit einer Bewertung der bereits vorhandenen Skills zu beginnen. Haben Sie Mitarbeiter, die in Python, Ruby oder einer ähnlichen Sprache programmieren können? Wenn ja, sollten Sie intensiv in sie investieren und ihnen individuelle Ziele setzen, die auf den Zeitplan für die Automatisierung abgestimmt sind. Wenn nicht, gibt es verschiedene Möglichkeiten. Gibt es in Ihrem Sicherheitsteam Mitarbeiter, die das Programmieren erlernen möchten? Haben einzelne Entwickler ein Interesse an der Cybersicherheit gezeigt? Diese Leute können Sie weiterbilden, die Entwickler in Sicherheit und die Sicherheitstechniker in Programmiersprachen. Damit das erfolgreich ist, müssen Sie jedoch die entsprechenden Ressourcen in die Weiterbildung investieren und die Schulungsziele an Ihren Automatisierungszielen ausrichten.

Wenn es in Ihrem ganzen Unternehmen kaum Programmierer gibt, lohnt es sich vielleicht, für eine kurze Zeit einen Berater einzustellen, der bereits in vielen anderen Unternehmen ähnliche Projekte durchgeführt hat. Achten Sie jedoch darauf, dass dieser Berater die Sicherheitsteams entsprechend einweist. Die besten Skripts nützen Ihnen nichts, wenn niemand in Ihrem Unternehmen sie nutzen oder aktualisieren kann. Wenn dieser Prozess im Gange ist, können Sie die Sicherheit vollständig in den Entwicklungsprozess integrieren.

5. Integrieren Sie die Sicherheit in den Entwicklungsprozess.

In diesem Schritt zeichnen Sie genau auf, wer wann welchen Code in welche Cloud-Umgebung(en) hochlädt. Wenn Sie das wissen, können Sie ermitteln, wo Sicherheitsprozesse und ‑tools implementiert werden sollten, um den Code effektiv zu schützen und die Entwickler möglichst wenig zu behindern. Beziehen Sie die Entwickler selbst unbedingt von Anfang an in diesen Prozess ein.

Fazit

Mit einer Sicherheitsstrategie für die Cloud, die sich auf die „5 Big Cloud“ konzentriert, können Sicherheitsteams aller Größenordnungen von den Vorteilen öffentlicher Clouds profitieren. Für zu lange Zeit haben das nur Entwicklerteams getan. Fangen Sie klein an und nehmen Sie dann schnell Fahrt auf.

在与数百位客户合作的基础之上，我们开发出了 5 大云安全策略。虽然并非完美无瑕，但如果使用得当，该策略能够帮助您的团队建立一套面面俱到的云安全策略。

图 1：5 大云安全策略

在由于人为失误造成的事件当中，主要原因之一是对环境缺乏足够的认知。– Nullmeyer、Stella、Montijo 和 Harden，2005 年

1.了解云的状况，获得深度的可视性。

如果要简化云安全性及合规性工作，需要先了解目前开发人员和业务团队如何使用云。首先应该了解影子 IT 对于云的使用情况，当然，还不能仅仅满足于此。您的团队可以通过 80/20 法则，了解需要最先关注哪个云平台。然而，安全团队不仅要了解正在使用哪些云平台，还要了解这些云平台内部正在运行的内容。这就到了云提供商的 API 发挥作用的时刻。

API 是将云和大部分本地环境区分开来的关键技术之一，它能够持续掌握云环境中的状况。您不仅需要对企业正在使用的云应用了如指掌，还应该利用云提供商的 API 持续跟踪下至元数据层中的所有更改。

2.建立防线，自动阻止最严重的云配置错误。

问问自己，云环境中有哪些配置（错误的配置或反模式）永远不该出现？例如，数据库直接接收来自 Internet 的流量。我们都知道这是“最坏的做法”，但是 Unit 42 的威胁研究表明仍有 28% 的云环境中存在这种情况。您可以制定一份初步的清单，并随着云安全计划的日益成熟而不断扩展这份清单。两则重要的说明：任何时候如果需要建立自动化的防护，强烈建议首先进行小规模的试验，从而确保不会出现意外结果（例如，由自身问题造成拒绝服务）。与您的开发团队紧密合作。如果未得到开发团队的支持，请不要尝试进行自动化防护。从计划伊始便应该与开发团队共同合作，从基础做起，为未来的成功打好基础。

3.标准是自动化的前提条件。

许多团队在尚未建立安全标准的情况下就开始谈论自动化。妥善的做法是随着时间的推移，逐渐将 80% 的任务自动化。标准建立得越完善，自动化的部分就会越简单。除非您是初创公司，否则不要设想在 90 天内即可实现从无自动化到完全自动化的骤变。在实现目标之前，这个过程通常至少会耗费企业 9 个月的时间。

4.培训并雇佣进行编程的安全工程师。

与大部分传统的数据中心不同，公有云环境由 API 驱动。安全团队需要利用 API 才能有效管理云中的风险。

根据企业的规模，首要任务是评估目前现有的能力。您的团队中是否拥有了解如何使用 Python 或 Ruby 这类语言进行编程的成员？如果是，请根据建立成熟的自动化防护的时间安排，大力培养这些团队成员。如果团队中没有这类成员呢？那么您有几种方法可供选择。寻找想要学习相关技术的成员，或在开发团队中进行调查来发现对安全防护抱有兴趣的成员。如果培训目标明确且具备适当的资源，那么可以向开发人员培训安全防护的技术，亦可向安全工程师培训编程技术。

如果编程不是企业的强项，一个不错的选择是选择一名在相关方面与多家企业有过合作经验的短期顾问。您绝对不会希望自己的团队面临一堆不知道如何修改或使用的脚本。在进行此过程的同时，您也将做好将安全防护完全嵌入到开发流程的准备。

5.将安全防护嵌入到开发流程中。

为此需要确定企业向云中推送代码的过程中，所涉及的人员、内容、时间和位置。在完成这一步后，您的目标就是为安全流程和工具找出造成干扰最小的插入点。在初期获得开发团队的支持是关键所在。

结语

不论安全企业的规模如何，通过构建以“5 大云安全策略”为重点的云安全策略，都可以享受到由公有云提供的各种优势，而长久以来只有开发团队从这些优势当中收益。从基础做起，为未来的成功打好基础。