雲端運算 - 資安趨勢部落格

關於整合安全解決方案,五個要問遠端管理模組廠商（RMM）的問題

2013 年 04 月 26 日2013 年 04 月 19 日 Trend Labs 趨勢科技全球技術支援與研發中心

作者：Ryan Delany

遠端管理模組（RMM）廠商通常都會對其核心產品提供整合的安全解決方案。但這些整合產品的安全功能如何？在之前的部落格文章裡，我提出五個要問你RMM廠商關於整合安全解決方案的問題。現在有另外五個問題讓你可以確認是否包含在解決方案裡。

1.      取得整合安全解決方案授權的程序為何？
有時你需要透過大量前期採購安全解決方案授權以獲得更好的價格，或是因為它們被成套銷售，讓你無法根據業務需求來彈性地增加或減少授權量。
先不談價格和任何前期成本，你是如何取得這些授權的？你需要向RMM廠商下定單，然後等待一段時間直到他們可以提供這些授權，因為他們需要轉單給安全解決方案廠商嗎？如果你在週末時進行新的部署，卻沒辦法即時啓動這程序的話會如何？你可以全年廿四小時無休的要求並取得授權嗎？
2.      取得整合安全解決方案技術支援的程序為何？
RMM廠商並沒有辦法去支援安全解決方案，因為他們缺乏知識和專業技能（意料之中，因為這安全解決方案並非他們所開發）。那你要如何獲得支援？你可以直接聯繫安全解決方案廠商嗎？還是你要將問題提交給RMM廠商，他們再轉給安全解決方案廠商？當你提交問題時，預期的平均回應時間是多久？更重要的是，你的客戶需要等多久？
3.      你與安全解決方案廠商的合約有多久？當合約到期時，會發生什麼事？
就跟你的業務一樣，你會跟客戶談判合同的長短，RMM廠商和安全解決方案廠商談判合約時，也會有個期限。重要的是要了解當這合約到期，RMM廠商決定不再續約，並切換另一個安全解決方案時，會有什麼影響。
當他們續簽合約時會影響到你嗎？當他們決定更換其他廠商為合作夥伴時呢？這些對你和你的客戶來說代表什麼？
繼續閱讀

軟體定義軟體軟體定義的歷史性一刻

2013 年 04 月 26 日2013 年 09 月 17 日 Trend Labs 趨勢科技全球技術支援與研發中心

作者：趨勢科技雲端安全副總裁Dave Asprey

「軟體定義“Software defined” 」是IT和雲端技術的最新流行語。有些人討厭它，因為幾乎就跟「雲端」一樣，行銷人員在真正產品出現前就開始忙著使用「軟體定義“Software defined” 」這名詞。雲洗白（Cloudwashing）是個真實現象，而且很容易就搭配使用。「軟體定義洗白」就沒那麼好上口了，而且會讓人覺得是跟網路相關的虛擬洗衣。

下面會介紹為什麼你該擁抱這名詞（我喜歡它甚至超過雲端），還有我們在「軟體定義」流行之前是用什麼名詞。

它非常流行。 VMware喜歡「軟體定義」到為了軟體定義資料中心去買下軟體定義網路（SDN）廠商Nicira。 EMC則到處都是軟體定義儲存。我在Arista Network的朋友們談論軟體定義雲端網路，而且很可能是SDN這名詞的發起者。（如果我錯了，而你知道是誰發明這名詞，請告訴我 – @daveasprey）

事實上這想法並不是新的。底下是我們以前的「軟體定義」。

任何基於策略（Policy-based）的解決方案

在一九九九年，我和別人一起為Prentice-Hall寫了一本三百五十頁，名為「企業級網際網路」的書，因為網路泡沫化的關係，所以從未出版過。在這本書裡，我寫了大量關於基於策略（Policy-based）和策略驅動（Policy-driven）架構是如何為網際網路所需，好去達到企業所期望的可用性和安全性水準。網路工程師已經談論策略和基於策略架構超過十年了。VLAN策略甚至是今日保持雲端網路區段的基本組成。

軟體定義和基於策略的差別是…行銷。再一次地，市場行銷影響很大。我數年前在Speedera（現在的Akamai）所建立的雲端服務稱為「彈性運算」，因為我沒有足夠的行銷智慧去想到「雲端」這個詞。總歸來說，它所做的跟基礎設施即服務（IaaS）雲端一模一樣：基於規則或策略來提供新虛擬機器。只是名字不對！

繼續閱讀

十大AWS安全秘訣：第四條，保護客戶端作業系統

2013 年 04 月 09 日2013 年 12 月 24 日 Trend Labs 趨勢科技全球技術支援與研發中心

作者：Mark Nunnikhoven

我們大約地討論了有關開發AMI的問題。現在我們要來看看如何保護運行在EC2和VPC虛擬機器上的客戶端作業系統。

AWS的建議

AWS已經發表了不少關於他們服務的文件。AWS安全最佳實作[PDF]和AWS風險與法規遵循[PDF]更是其中非常棒的安全資源。在最佳實作這份文件中，「防護你的應用程式」章節（第4頁）底下，他們提出了一些建議，歸納為以下幾點：

盡快安裝修補程式
對於作業系統和服務要使用建議的安全設定
測試，測試，再測試

這真是非常正確而有效的建議，讓我們來看看這些建議實際應用時會面臨的問題。

儘快安裝修補程式

這是IT經常會聽到的一句話。我們都知道需要更新修補程式，但這過程相當痛苦，通常這痛苦會跟測試有關。當你的應用程式放在雲端環境，你不用那麼經常去對運作中的系統更新修補程式，因為基礎AMI可以讓這事情變得更加容易些。

你可以在測試環境中部署基於你基礎AMI的虛擬機器，安裝修補程式，接著再執行所有所需的測試。如果修補程式不會影響到你的設定，就建立更新過的基礎AMI。下一步就是排定時間將新的AMI部署到作業環境上。取決於你的應用程式，甚至可能和之前的版本並行運作一段時間以消除停機時間。

使用建議的安全設定

大多數作業系統和服務都會有建議設定。仔細閱讀它們！也可以到有信譽的資料來源研究所建議的設定。整理這些建議設定，接著根據你的需求來完成設定。請記住最小權限原則，只在有絕對需要時才開啟服務或功能。

繼續閱讀

十大AWS安全祕訣：第二條，密碼策略和多因子身分認證

2013 年 03 月 12 日2013 年 12 月 24 日 Trend Labs 趨勢科技全球技術支援與研發中心

作者：Mark Nunnikhoven

在介紹如何利用AWS身份和存取管理來保護資源的文章裡，Justin介紹了AWS身份存取管理（IAM）的基本知識。今天我們要來看看如何使用IAM來設定密碼策略和多因子身分認證。

密碼策略（Password Policies）

使用強密碼的重要性是眾所周知的。大多數組織都已經有了密碼策略。這種策略通常會定義複雜度（像是包含多少個數字、特殊字元和密碼長度等），以及變更週期（像是每九十天就必須變更密碼）。

有些策略會更進一步，對於不同的設備或角色有不同的要求。CSIS的前廿項控制裡的第12項 – 「控制管理權限的使用」裡介紹了密碼策略的強化。就是要確保具有管理存取權限的人使用複雜密碼，並且必須一年變更好幾次。

IAM目前提供了一連串的設定來強制執行密碼策略。你可以為你的AWS帳號設定密碼策略。這策略可以讓你定義密碼的複雜度，但並不能設定變更週期。

現在就開始使用密碼策略是很棒，但你需要手動要求使用者定期變更密碼，或是採取別的方法加強……或是雙管齊下！

多因子身份認證

AWS的多因子身份認證（MFA）正是我們用來加強密碼策略的方法。

那麼，到底什麼是MFA？就是使用一個以上的認證因子來驗證誰是使用者。有三個常見因子：你知道什麼東西（something you know）、你擁有什麼東西（something you have）和你的生物特徵（something you are）。

我們的使用者已經具備了一個因子，就是密碼（使用者知道的東西）。對於AWS，第二個因子是使用者擁有的東西。可能是硬體認證裝置（可向AWS購買）或用軟體認證裝置，安裝在智慧型手機或其他設備上。

這些認證裝置會顯示隨機生成的數字，必須在使用者輸入自己的帳號和密碼登錄AWS管理控制台時輸入。這數字每隔幾秒鐘就會變化一次，以確保使用者在登錄時有認證裝置在身上。

現在想要認證成功，就必須輸入正確的帳號密碼，加上由正確認證裝置在使用者登錄當下所產生的數字。

繼續閱讀

< 雲端運算 >十大AWS亞馬遜網路服務安全祕訣：第一條，用IAM保護你的資源

2013 年 03 月 05 日2013 年 12 月 24 日 Trend Labs 趨勢科技全球技術支援與研發中心

在接下來的幾個星期，我們將會探討如何防護AWS（亞馬遜網路服務）環境的最佳做法。在我們深入到防護你的虛擬機器、應用程式和資料之前，讓我們從最頂端開始。

作為AWS共享責任安全模型的一部分，AWS消費者防護好自己的服務可以發揮重要的作用。早在二〇一二年十一月的AWS re:invent大會上，Max Ramsay就將AWS與CSIS廿個關鍵安全控制對應，作為進一步了解AWS和客戶端（你）之間共同責任的框架。關鍵控制的第十二項是控制管理權限使用，負起保護責任是身為AWS用戶的你所必須加以正視的。在接下來的幾個星期，我們會聚焦在你所需要負起責任的關鍵控制。

在虛擬化或雲端世界，管理權限就好比是作業系統上的管理者帳號。不過，現在你有更多組強大的身份需要管理，好存取AWS控制台和API。

收起你的AWS管理者（root）帳號，利用IAM（身份存取管理）來啟動存取權限

當你開始使用AWS，你會獲得一組帳號和密碼。這個帳號擁有存取你所有AWS資源和帳務資訊的權限。不要跟任何人分享！我知道有某個經理跟他的團隊共享帳號，他們很快就發現可以用經理的信用卡在Amazon.com上買東西！

確認該帳號安全後，接著進到控制台上的IAM 選項，開始定義群組和使用者。