2025年11月2日 星期日

[AWS] 雲端玩家大集合!AWS Community Day 2025 Taiwan:不只是技術,根本是一場大型社群派對!

Written by: AWS Community Builder Sheng Hau Wang


事隔兩個月了,才有空坐下來紀錄一下今年的 AWS Community Day活動以及我所負責的部分

AWS Community Day 2025 Taiwan 當天踏入會場,一定會被那股熱情洋溢的氣氛所震撼。這不是一場官方制式的高層會議,而是由台灣在地 AWS 社群夥伴們(AWS User Group Taiwan)一手打造、專屬於技術人的年度派對!整個活動場地簡直像是一個大型的科技嘉年華。

志工們忙碌的身影、講師們專業又幽默的講解,共同構築出這個友善且知識密度極高的環境。對於許多 AWS 鐵粉來說,這一天不只是來學習新知,更是來見見那些在網路上互相討論技術,卻素未謀面的「雲端夥伴們」。當天大家不分你我,一起在知識的海洋中暢遊,那種屬於技術人的熱血與情誼,絕對是 Community Day 最獨一無二的風景!


今年的議程設計,完全展現了社群的力量:夠深、夠廣、夠實戰! 每一場議程都像是一份濃縮的實務報告,講者們毫不藏私地分享他們在專案中如何「從地上爬到天上飛」的寶貴經驗。從最熱門的 Generative AI 應用,教你如何利用 AWS 服務快速部署一個成本可控的 AI 服務;到讓許多人頭痛的 DevOps 流程,有講師深入解析如何用 Infrastructure as Code (IaC) 達成真正的自動化部署,徹底擺脫手動佈署的夢魘。甚至連相對冷門但重要的 FinOps (雲端成本管理) 都有專場,手把手教大家如何找出雲端中的「隱藏水費」,把錢花在刀口上。這種完全從實戰角度出發的內容,遠比教科書上的理論更具價值。





如以為 Community Day 只有聽講,那你就大錯特錯了!活動現場最吸睛的環節之一,莫過於緊張刺激的 AWS Game Day 英雄聯盟。這個高度遊戲化的實戰挑戰,要求參賽隊伍在有限時間內,運用 AWS 各項服務解決一系列複雜的技術問題。現場氣氛既像考場又像電競比賽,參賽者們面對螢幕、敲擊鍵盤,腦力激盪,為了解鎖下一關而奮鬥。此外,還有專門的 Chalk Talk 討論區,讓技術大神們圍坐一圈,以白板繪圖的方式進行深度技術交流,從架構設計到疑難排解,都能得到最即時的回饋。旁邊的 Builder Cards 挑戰區更是讓許多人流連忘返,透過解題小遊戲的方式,把學習變得更有趣。這些互動環節的設計,鼓勵大家動手做 (Hands-on),真正把在議程中學到的知識轉化為實際操作能力,讓一整天的活動充滿了樂趣、挑戰與成就感!

隨著活動接近尾聲,會場內的交流熱度卻絲毫未減。許多人在茶點區、攤位區依舊熱烈地討論著白天的收穫,互相交換名片,成功地將線上的技術交流延伸到線下的真實連結。AWS Community Day 2025 Taiwan 不僅是一場技術盛會,更是一次對台灣雲端社群力量的最好展現。它證明了,當一群人擁有共同的熱情與目標時,能夠創造出多麼強大且正向的能量。每一位志工的付出、每一位講者的分享,以及每一位參與者的熱情,都是這場活動成功的關鍵。活動落幕,但社群的連結與學習的熱情卻不會停止。讓我們帶著滿滿的戰利品、充足的知識和新的友誼,繼續在雲端的世界裡前進。期待我們明年,在更盛大、更精彩的 AWS Community Day 再相會!

這次同樣擔任了活動的宣傳組,因為工作忙碌的關係沒辦法很全力的Support整場活動,因此一開始報名就先從宣傳著手,跟著組員一起設計宣傳文宣以及製作相關圖文,也想透過一點點的心力來幫助整個活動,也附上一些參與現場活動的照片記錄起來

我的報名牌,報到時忘記用志工身份的名義報到,因此是拿到一般的會眾名牌


現場活動的照片(大合照)

志工合照(那時已經先行離開了,才沒有入鏡)

現場讓我最衝擊的一句話分享給大家
An unprecedented change is coming to my industry because of AI. I don't know how to be prepared! (人工智慧將為我的產業帶來前所未有的變革。我不知道該如何做好準備!)

隨著科技的進步,我們該如何擁抱新技術來協助我們並且提升我們的工作效率,這是很需要探討的議題,沒有什麼人是無法被取代的,要有效率用資源來讓你成為無法被取代的人才,AWS提供了很多AI相關資源及技術讓大家可以應用,我們都可以透過社群活動或是AWS User Group Taiwan上的交流來精進自己的技術成為無法被取代的那一位。


現場還有拿到小贈品,可愛的吊飾剛好掛在包包上,這次也帶了好幾位朋友一起與會,讓他們對AWS的服務又更感興趣了,以及透過這次活動的交流也加深他們想在公司內推動數位轉型的決心

歡迎對AWS有興趣的朋友可以加入我們在Facebook上的社群一起交流,每個月我們都會舉行線上或是線下的活動,像是技術分享或是新服務的介紹等..在社團內遇到在服務上使用的任何問題都可以在上面發文交流,都會有夥伴們無私的分享及討論,覺得透過這樣的方式進行交流進步的速度非常的快,可以點選[1] 的連結加入

連結[2] 是今年 Communtity Day的活動網站,有興趣的朋友也可以參觀看看

最後來宣傳一下我們 AWS Community Builder 計畫,為熱衷於技術的 AWS 愛好者與新興技術意見領袖,提供技術資源、教育訓練以及交流機會。該計畫歡迎致力於分享知識並積極與技術社群互動的個人申請參加。歡迎一起加入我們的行列吧,報名連結[3]


[1] https://www.facebook.com/groups/286709044738947
[2] https://awscmd.tw/
[3] https://builder.aws.com/community/community-builders




2025年6月9日 星期一

[AWS] AWS 雲服務下的 ISO 27001

Written by: AWS Community Builder Sheng Hau Wang 


在去年10月參加了 BSI 所舉辦的 ISO 27001:2022 的主導稽核員訓練後,把自己使用 AWS 雲服務可能會對應到 ISMS 條款,以上內容僅供我個人對於AWS雲服務多年實務上使用以及對於條款的初步了解,稍微整理了一下,如內容有誤或是您有不一樣的見解,歡迎下面一起討論

在現今數位轉型浪潮下,越來越多組織選擇採用雲端服務,如Amazon Web Services (AWS),以獲取其彈性、可擴展性與成本效益。然而,將資訊資產遷移至雲端環境,也帶來了新的資訊安全挑戰與管理複雜性。


對於已建立或正計劃導入符合ISO 27001標準之ISMS的組織而言,確保雲端服務的使用符合其資訊安全要求至關重要。提供了組織應如何實作資訊安全控制措施的指導方針,本文件旨在協助組織理解在使用AWS服務時,如何將ISO27001的控制措施落實,並為ISMS稽核做好準備。


使用雲端服務的核心概念之一是「共同責任模型」(Shared Responsibility Model)3。在AWS的環境中,AWS負責「雲端本身的安全性」(Security of the Cloud),這包括了基礎設施、硬體、軟體、網路以及託管雲端服務設施的實體場所安全。相對地,組織(即雲端服務客戶)則負責「雲端中的安全性」(Security in the Cloud)。這涵蓋了客戶的資料、平台、應用程式、作業系統、網路組態以及身分與存取管理等方面。


ISMS的目標是依據組織的資訊安全風險評鑑結果,決定並實作一組合適的控制措施.。因此,組織在使用AWS時,必須清楚辨識其在共同責任模型下應負擔的「雲端中的安全性」控制措施,並將這些措施整合到其


整體ISMS框架中。稽核的重點將在於驗證組織是否已識別相關風險,實作了適當的控制措施,並能證明這些控制措施在AWS環境中得到有效執行與持續管理


ISO 27001:2022版本,特別新增了針對雲端服務的控制條款,並更新及擴展了其他相關控制領域,為組織在雲端環境中的安全管理提供了更具體的指引。


特別關注了雲端服務的使用安全,其核心體現於以下控制措施:

5.23 使用雲端服務之資訊安全 (Information security in the use of cloud services)◦

目的: 規定並管理使用雲端服務之資訊安全性。


說明與應答: 這是最直接相關的條款。組織需證明已建立一套系統化的過程來處理雲端服務的整個生命週期,從「獲取、使用、管理」到「退出」。


▪風險識別與要求事項: 組織應已識別與使用AWS相關的資訊安全風險及要求,並進行風險評鑑。需展示風險評鑑報告,以及針對AWS服務的風險處理計畫,說明殘餘風險如何被接受。


▪選擇與範圍: 需有AWS服務的選擇準則及明確的使用範圍文件。


▪角色與責任: 明確定義組織內部與使用AWS相關的角色與責任,並清晰闡述與AWS之間的共同責任分界。例如,誰負責管理IAM使用者?誰負責組態安全群組?誰負責監控CloudTrail日誌?


▪控制措施實作: 組織需展示如何在AWS環境中實作其負責的控制措施。


•身分識別與存取管理 (Identity and Access Management, IAM): 如何管理AWS帳戶、使用者(IAM Users)、群組(Groups)、角色(Roles)及政策(Policies),對應到5.15、5.16、5.17、5.18條。


•需展示IAM政策設定、使用者權限審查紀錄等。特別是特殊權限的管理 (8.2條)。


•組態管理 (Configuration Management): 如何安全組態AWS服務,如EC2實例、S3儲存桶、VPC網路等,對應到8.9條。需展示AWS服務的組態基準、組態審查紀錄,或使用IaC (Infrastructure as Code) 工具的組態文件。


•資料保護 (Data Protection): 如何保護儲存在AWS服務中的資料,包括分類分級 (5.12條)、傳送安全 (5.14條)、刪除 (8.10條)、遮蔽 (8.11條)、備份 (8.13條) 及加密技術的使用 (8.24條)。

需展示資料分類分級文件、S3加密設定、RDS加密設定、KMS金鑰管理程序、備份策略與測試紀錄等。


•網路安全 (Network Security): 如何保護AWS網路環境,包括網路區隔 (8.22條) 和網路安全控制 (8.20條)。需展示VPC設計圖、安全群組/NACL規則、VPN/Direct Connect安全組態等。

日誌與監控 (Logging and Monitoring): 如何收集、保護和分析AWS環境的活動日誌 (8.15條),以及如何監控異常行為 (8.16條)。需展示CloudTrail、CloudWatch Logs、VPC Flow Logs的設定與日誌分析程序、安全監控工具(如GuardDuty, Security Hub) 的使用及告警處理流程


•資訊安全事故管理: 如何將AWS環境中偵測到的事件(如透過GuardDuty)納入組織的事故管理流程,對應到5.24至5.28條。需展示事故回應計畫中包含雲端環境應急處理的部分,以及事故發生後的日誌分析與證據蒐集流程。


•營運持續及備援 (Business Continuity & Redundancy): 如何利用AWS的多區域、多可用區設計,以及備份服務來滿足營運持續和資訊處理設施備援的需求,對應到5.29及8.14條。需展示營運持續計畫、備援架構設計及測試紀錄。


▪協議審查: 需審查與AWS的服務協議(Terms of Service, SLA等),了解其涵蓋的安全條款,以及組織對供應商的資訊安全保證如何取得及利用。雖然AWS的協議通常不可協商,但組織需證明已理解協議中AWS提供的安全能力和其責任範圍,並將此納入組織的風險評鑑和控制措施設計中


▪供應者關係管理: 雲端服務供應商是組織重要的供應者。因此,與供應者關係相關的條款,如5.19至5.22條,也高度相關。組織需展示如何評估AWS的安全能力(例如,透過AWS的合規認證報告,如SOC 2, ISO 27001認證等,如何在協議中闡明安全要求(即使是標準協議,組織也需理解其中的安全承諾),以及如何監視和審查服務交付。


▪退出策略: 需有從AWS服務退出的計劃或程序。

在 AWS 雲服務環境中實現 ISO 27001:2022 的符合性,是一項需要全面規劃和持續執行的任務。作為主導稽核員,我會著重於組織如何將 ISO 27001 的要求與 AWS 的共享責任模型深度融合。關鍵在於組織對其在雲端中的安全責任有清晰的認知,並能展示如何透過 AWS 的原生安全服務和自身建立的控制措施,有效地管理資訊安全風險。

成功的關鍵不僅在於導入單一的技術解決方案,更在於建立一個健全的治理框架、明確的職責分工、完善的流程管理以及持續的監控與改進機制。組織必須證明其 ISMS 能夠適應雲端環境的動態性,並透過有力的證據(如配置日誌、審計報告、安全事件記錄)來支持其合規聲明。

通過上述的應答策略,組織不僅能滿足 ISO 27001:2022 的要求,更能藉此機會全面強化其在 AWS 雲環境中的資訊安全態勢,為業務的穩健發展提供堅實的保障。

針對 AWS 哪些服務有符合 ISO 27001:200 的規範,可參考官方文件 [1] [2]

AWS 擁有符合 ISO/IEC 27001:202227017:201527018:201927701:201922301:201920000-1:20189001:2015CSA STAR CCM v4.0 的認證。以下列出認證涵蓋的 AWS 服務。

除非明確排除,否則服務的所有功能都已納入。請參閱 AWS 文件以了解服務功能。


[1] 已通過ISO 27001 認證之 AWS 服務列表

[2] ISO/IEC 27001:2022 合規 - Amazon Web Services (AWS)

2025年1月24日 星期五

[AWS] AWS re:Invent 2024: 新服務介紹 Security Incident Response

Written by: AWS Community Builder Wang Sheng Hau


這次拖到現在才回頭來看 AWS re:Invent 2024 相關的議程和新產品更新資訊,

因為剛好在去年十月面臨職涯轉職,好在也是從事資安的工作內容,資訊安全稽核員,

可以繼續針對資安層面的議題來繼續跟大家討論。


往年都會把在 AWS re:Invent 上聽到跟 Security 相關的服務或是新資訊整理出來分享給大家,

今年也不例外也。

在 re:Invent 2024上宣布全面推出 AWS 安全事件回應 [1],這是項新服務,可協助您準備、

回應安全事件並從中復原。該服務提供對安全調查結果的自動監控和調查,

以將您的資源從日常任務中解放出來,提供通訊和協作功能以簡化回應協調,

並直接與 AWS 客戶事件回應團隊 (CIRT) 進行全天候存取。


安全事件回應透過 AWS Security Hub 與 Amazon GuardDuty 等現有偵測服務和第三方工具進行整合,

以快速地檢閱安全警示、升級高優先順序調查結果,並在您允許的情況下實作遏制動作。

減少了團隊需要分析的警示數量,節省了時間,該服務集中了所有與事件相關的通訊、

文件和動作,讓內部和外部利害關係人之間的協調事件回應成為可能,

並將協調時間從幾小時縮短到幾分鐘。

您可以在安全事件期間預先設定事件回應團隊成員、設定自動通知、

管理案例權限以及使用視訊會議和主控台內傳訊等通訊工具。

安全事件回應可以主動監控並分類來自 GuardDuty 和安全中心的發現。

它根據您的特定客戶資訊(例如已知 IP 位址和 AWS 身分和存取管理 (IAM) 實體)採用智慧過濾。

對於需要注意的發現,安全事件回應部門會立即採取行動。

其實這個功能推出就是大大的來減少資安同仁們對於資安事件的收集和分析所需花費的時間,

並且可以更準確更快速地去掌握實際狀況,安全事件發生後,

取得所有與事件相關的活動的綜合案例歷史。這段全面的歷史記錄有助於進行結構化的事件後審查,

使您能夠評估回應的有效性並找出改善安全態勢的機會。

但相對來說就價格來看她也是不便宜,就取決於客戶對於公司資產價值以及商業考量去做決定了[3]


更完整的說明可以參考 AWS 官網文件[2]


[1] https://www.youtube.com/watch?v=5Bx7f_e4dDM&ab_channel=AWSEvents

[2] https://aws.amazon.com/tw/security-incident-response/features/

[3] https://aws.amazon.com/tw/security-incident-response/pricing/

2024年10月7日 星期一

[GCP] Billing Account 下專案內的 Cloud SQL版本

 起因是有客戶遇到了Google Cloud SQL for MySQL版本 5.6 和 5.7 以及 Google Cloud SQL for PostgreSQL版本 9.6、10、11 和 12 將於2025 年 2 月 1 日過渡到擴充支援。

以下資料庫引擎主要版本已在各自社區內終止生命週期:

  • MySQL versions 5.6 and 5.7

  • MySQL版本 5.6 和 5.7

  • PostgreSQL versions 9.6, 10, and 11 (version 12 will reach end-of-life in November 2024)

  • PostgreSQL版本 9.6、10 和 11(版本 12 將於 2024 年 11 月終止生命)


因此詢問我能如何快速的去排查公司旗下 Billing account 內所有 Project 專案內的 Cloud SQL Instance 版本

這邊建議客戶使用 Google Cloud Asset Inventory 資產盤點服務 [1]
首先進入到Google Consone 點選 IAM > 資產儲存庫 > 資源 > 查看更多 > 搜尋 SQL

你在 Console 上看到的東西會很有限
這時候我們一樣透過 Cloud Shell 的方式去使用指令來查詢到更完整的資訊

點選右上角 Cloud Shell > 授權 > 輸入指令 gcloud asset search-all-resources   --scope='organizations/修改成自己的 Org ID'   --asset-types='sqladmin.googleapis.com/Instance'   --read-mask='name,versionedResources' | egrep '(---|name|databaseVersion)'


會把此 Org 下的所有 SQL Instance 列出來並且輸出 名稱和 SQL 版本 [2]




以上就是透過指令的方式可以更準確的撈出比較細節的內容


[1] https://cloud.google.com/asset-inventory/docs/overview
[2] https://cloud.google.com/asset-inventory/docs/searching-resources#search_resources

2024年10月4日 星期五

[GCP] Compute Engine VM 規格查詢

 以往再 Google Console 上面我們要查看你所使用的 VM 規格

不外乎就是進到 Console 介面去點選,但其實可以發現他顯示的內容相當的少


點進去看頂多看到機器名稱和所在 Region,但是你有沒有發現你無法看到你開機器的 CPU 規格或是記憶體 Mem 的大小

但是我們又很需要知道其資訊,因為可能盤點時需要或是專案排查需要,這時候我們可以透過 Cloud Shell 這個功能再搭配上簡單的指令就可以一目了然你專案內所有 VM 的規格了

首先我們點選右上角的符號進入到 Cloud Shell 畫面,他會開啟再畫面的下方


這時我們輸入指令 "gcloud compute instances list"
如果是非客製化的機器就會顯示如圖上的 e2-micro 等一般通用規格

但是我們想查找的是客製化的,我自己定義的機器規格,如 8Core 16GMem 之類的

這時我該怎麼做呢? 一樣輸入指令 "gcloud compute instances list" 就可以看到了


2024年9月29日 星期日

[AWS] AWS Community Day Taiwan 2024

 AWS Community Day Taiwan 2024


Written by: AWS Community Builder Wang Sheng Hau



比起以往都是以會眾的方式參與活動,今年特別報名了志工的角色。

原本以為可以擔任現場的活動組志工,無奈因為要照顧小孩的關係不能幫忙

臨時跟總招 Franky 和 Eric 討論可否改成宣傳組志工,並且負責了一個文案的編寫及宣傳。

我只負責文案的部分,精美的美編是由另外一位夥伴負責,真的非常的優秀

加上參加了今年七月舉辦的 AWS USG 年中感謝祭,知道再舉辦 AWS Community Day 是多麼的辛苦,因此也想說盡自己的一點微博之力來幫忙活動能更順利 [1]

雖然沒能參與到完整的議程,但還是有稍微去聽了一下 Scott Hsieh 的 Amazon Athena:初識雅典娜,連結智慧的火炬 Workshop,也跟同為 AWS Community Builder 的朋友 Ming 合照了,好開心能見到你


最後也要感謝各位 UGL 、講者、40位志工和 30 位 AWS educate 的小夥伴們~ 

我明年一定會當完整的志工好好幫助大家的

AWS Community Day Taiwan 2025 我們明年見

 



[1] https://awscmd.tw/#:~:text=%E9%AD%8F%E4%BB%B2%E5%A8%81-,%E5%BF%97%E5%B7%A5,-%E4%B8%80%E5%80%8B%E4%BA%BA%E7%9A%84%E5%8A%AA%E5%8A%9B


[2] https://awscmd.tw/


2024年6月12日 星期三

[AWS] Amazon Q Business Workshop 透過生成式 AI 協助提升員工生產力 EP2

 Written by: AWS Community Builder Wang Sheng Hau


再上一章節 EP1 我們學到了該如何建立 Amazon Q 的應用程式,再這個章節我們來擴大 Q 的資料來源及增加他的能力值吧!!!


接下來我們進入到建立好的 App “kevin-workshop-app-01” 內


Step1 . 點選 Add Data Source > Add File (這邊選擇上傳 Html 檔案)


Step2. 上傳選擇的五個 Html 檔案,你也可以上傳 txt 檔案等等

Step3. 接下來就可以回到 Q 上面去詢問文檔內的內容了



舉例 : 假設今天建立了一個公司內部使用的問答系統,我就可以把一些非機敏資料的檔案上傳給 Q 讓他學習及查詢,上傳了公司的 HR 員工手冊 , 這樣我在 Q 上面詢問請假相關問題,Q 就會去彙整這些資料進行回答,對於剛到職的新人來說是多麼的方便及便利


同樣的除了我可以透過文件上傳,我也可以讓 Q 去爬蟲網頁的內容


Step4. 點選 Add Data Source > WebCrawler > 輸入來源名稱 > 選擇 Soure URLs >貼上 URL

Step5. Sync 範圍選擇 Sync 這個 Domain 以及 Subdomain 就好,不然會花很多時間再爬網頁

Step6. 新增完成後就會開始跑同步,這樣你問的問題他也同時會去撈取你 URL 網頁內的資訊

Step7. 這次我們新增來至 S3 Bucket 的資料

點選 Add Data Source > Amazon S3 > 填寫來源名稱

Step8. 填寫 S3 Bucket 來源位置 > 選擇你要 Sync  的程度以及多久 Sync 一次

Step9. 選擇你要給 Sync Bucket 的路徑 > 這邊選擇 / 下面的 Data 目錄


Step10. 等他 Sync 完畢即可


通過上面增加 Data Source 的方式,我們把 Q 的能力提升了不少,從公司內部文件,特定 URL ,到 S3 Bucket 內的資料,透過這些增加資料來源的方式我們大大提升了 Q 的問題及回答資源

這樣他就可以是一個很完整的公司內部小助手,你可以問他請假流程,可以問他部門組織,甚至可以問他公司某個同仁的分機或是 Email 是多少,這都取決於你提供了多少檔案給他


再次提醒,盡量不要給予含有個資或是公司機敏內容的檔案去做訓練和資料來源,可大大避免資安事件的發生


相關的 Data Source 新增也可以參考 [1] 的步驟進行



[1] https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/connect-data.html