[AWS] AWS RI / Saving Plan 說明以及差異

 Written by: AWS Community Builder Wang Sheng Hau

前陣子客戶在使用 AWS 服務時對於節費的部分有一些疑問

因此介紹給客戶 RI / Saving Plan 的概念,下面稍微簡短說明一下何謂 RI / Saving Plan 以及其中差異

Reserved Instances (RI)： AWS RI 是一種購買計算資源（如 EC2 實例、RDS 資料庫實例等）的方法，用戶事先支付一筆費用，然後在特定時間內使用這些資源。通常，RI 提供比按需價格更大的折扣。RI 分為標準 RI 和可變 RI（Convertible RI）。標準 RI 提供更大的折扣，但限制了資源的靈活性。可變 RI 允許更多的靈活性，但折扣可能會較低。

Savings Plans： Savings Plans 是一種更靈活的儲蓄方法，用戶可以購買一定數量的計算費用，而不需要事先指定特定的實例類型或區域。它們提供了比標準 RI 更大的彈性，用戶可以在多個實例類型和區域之間進行轉換。Savings Plans 適用於更廣泛的場景，並且通常提供具有競爭力的價格折扣。

兩者都是可以幫助在使用 AWS 上進行節省成本的服務

Reserved Instances (RI):

• 適用於 EC2、RDS、ElastiCache、Redshift 等特定 AWS 服務。
• RI 是預先購買的虛擬伺服器實例的容量，以一定的時間期限使用，並享有折扣優惠。
• RI 提供選擇「區域範圍」（Region Scope）或「區域範圍+可用區域」（Region and Availability Zone Scope）的購買選項。
• RI 提供「標準 RI」和「轉換 RI」兩種選項，可用於靜態工作負載或可彈性調整的工作負載。
• RI 可以提供更大的成本節省，但相對價格較高，並且需要更多的管理和計劃。

Savings Plans:

• 適用於 EC2、Fargate 等多種 AWS 服務。
• Savings Plans 是一種更靈活的儲備資源計劃，提供對基於使用率的成本優化。
• Savings Plans 不需要事先購買特定的實例，而是根據計算需求的使用率提供折扣。
• Savings Plans 提供「區域範圍」（Region Scope）的購買選項。
• Savings Plans 提供「計算型」（Compute）和「EC2 Instance Family」兩種選項，可選擇更廣泛的應用範圍。
• Savings Plans 提供更大的靈活性，並且在各種使用率模式下提供成本節省。

下表列出了 AWS RI 和 Savings Plans 的主要差異：

更多關於 RI 以及 Saving Plan 更詳細的說明可以參考 AWS 官方文件的介紹 [1] [2]

Ref

[1] https://aws.amazon.com/tw/aws-cost-management/reserved-instance-reporting/

[2] https://aws.amazon.com/tw/savingsplans/

         

[AWS] AWS Route53 private zone cross account

  Written by: AWS Community Builder Wang Sheng Hau前幾天跟朋友聊天聊到一個需求

他們想做 A account開 Route53 private zone 讓 B account 也可以使用到

於是貼了文件給他 [1] 

但是他們想透過 Iac 的方式來達成,不想透過 Web UI 來進行

因此找了 AWS CLI 的指令給他 [2],他還是不滿足,於似乎就找了 Cloudformation 的解法了 [3]

AWSTemplateFormatVersion: '2010-09-09'
Description: Create VPC and PHZ association

Parameters:
  SourceAccountId:
    Type: String
    Description: The AWS Account ID where the PHZ is hosted
  PHZName:
    Type: String
    Description: The name of the Private Hosted Zone

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: "10.0.0.0/16"
      EnableDnsSupport: true
      EnableDnsHostnames: true

  MyVpcDnsRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - arn:aws:iam::${SourceAccountId}:root
            Action: sts:AssumeRole

  MyVPCAssociation:
    Type: AWS::Route53::VPCAssociationAuthorization
    Properties:
      HostedZoneId: !FindInMap [PHZMap, !Ref "AWS::Region", PHZId]
      VPCId: !Ref MyVPC
      VPCRegion: !Ref "AWS::Region"

Mappings:
  PHZMap:
    us-east-1:
      PHZId: "PHZID-1234567890abcdef0"  # Replace with your PHZ ID for us-east-1
    us-west-2:
      PHZId: "PHZID-0987654321fedcba0"  # Replace with your PHZ ID for us-west-2

此模板示範了如何創建一個 VPC（MyVPC）並將其與指定的 PHZ 關聯。請注意以下事項：

模板使用了兩個參數：SourceAccountId（PHZ 所在的 AWS 帳戶 ID）和 PHZName（PHZ 的名稱）。

它創建一個 VPC，啟用了 DNS 支援和主機名稱解析。

它創建一個 IAM 角色（MyVpcDnsRole），該角色允許來自 SourceAccountId 的 AWS 帳戶假設該角色。

最後，它使用 AWS::Route53::VPCAssociationAuthorization 來關聯 VPC 和 PHZ。

您需要替換 PHZMap 中的 PHZ ID，以確保它匹配您的 PHZ 資源。此外，請注意，實際的 CloudFormation 模板可能需要包括更多的資源和設定，以滿足您的具體需求。這個範例僅供參考，您可以根據自己的需求進行修改和擴展。

參考文件

[1] https://docs.aws.amazon.com/zh_tw/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html

[2] https://repost.aws/knowledge-center/route53-private-hosted-zone

[3] https://docs.aws.amazon.com/zh_tw/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html

[AWS] re:Inforce 2023 Security 產品資訊 highlights

  Written by: AWS Community Builder Wang Sheng Hau 在2023/7/13 - 14 兩天的議程中,針對了 AWS Security 的產品有近一步的更新

這邊節錄了一些重點內容分享給大家

• Amazon Verified Permissions — Verified Permissions 是針對您構建的應用程序的可擴展權限管理和細粒度授權服務。該服務通過外部化授權和集中策略管理來幫助您的開發人員更快地構建安全的應用程序。開發人員可以通過在應用程序內實施最小權限和持續驗證來使應用程序訪問符合零信任原則。安全和審計團隊可以更好地分析和審計誰有權訪問應用程序內的內容。亞馬遜驗證權限使用Cedar，一種用於訪問控制的開源策略語言，使開發人員和管理員能夠使用上下文感知訪問控制的角色和屬性來定義基於策略的訪問控制。
• Amazon Inspector 對 Lambda 函數進行代碼掃描— Amazon Inspector現在支持對AWS Lambda進行代碼掃描函數，擴展了掃描 Lambda 函數和相關層以查找應用程序包依賴項中的軟件漏洞的現有功能。Lambda 函數的 Amazon Inspector 代碼掃描會掃描您在 Lambda 函數中編寫的自定義專有應用程序代碼，以查找安全漏洞，例如注入缺陷、數據洩漏、弱加密或缺失加密。在檢測到 Lambda 函數或層中的代碼漏洞後，Amazon Inspector 會生成可操作的安全結果，其中提供了多個詳細信息，例如安全檢測器名稱、受影響的代碼片段以及解決漏洞的修復建議。結果匯總在 Amazon Inspector 控制台中，並與AWS Security Hub和Amazon EventBridge集成簡化工作流程自動化。
• Amazon Inspector SBOM 導出— Amazon Inspector 現在能夠以多種行業標準格式（包括 CycloneDx 和軟件包數據交換 (SPDX)）導出整個組織中監控的資源的綜合軟件物料清單 (SBOM)。借助這項新功能，您可以使用自動化且集中管理的 SBOM 來了解有關軟件供應鏈的關鍵信息。這包括有關資源中使用的軟件包的詳細信息以及相關的漏洞。SBOM 可以導出到Amazon Simple Storage Service (Amazon S3)存儲桶並下載以使用Amazon Athena或Amazon QuickSight進行分析可視化軟件供應鏈趨勢。只需在 Amazon Inspector 控制台中單擊幾下或使用 Amazon Inspector API 即可使用此功能。
• Amazon CodeGuru Security — Amazon CodeGuru Security提供了一套全面的 API，旨在與您現有的管道和工具無縫集成。CodeGuru Security 是一種靜態應用程序安全測試 (SAST) 工具，它使用機器學習來幫助您識別代碼漏洞並提供可用作修復的一部分的指導。CodeGuru Security 還針對某些類別的漏洞提供上下文代碼補丁，幫助您減少修復代碼所需的工作量。
• Amazon EC2 Instance Connect 終端節點— Amazon Elastic Compute Cloud (Amazon EC2)宣布支持通過 Amazon EC2 Instance Connect 終端節點 (EIC 終端節點) 在私有子網中使用 SSH 或 RDP 連接到實例。借助此功能，您可以使用 SSH 或 RDP 從互聯網連接到您的實例，而無需公共 IPv4 地址。
• AWS 內置合作夥伴解決方案— AWS 內置合作夥伴解決方案是與 AWS 專家共同構建的，有助於確保嚴格遵循 AWS Well-Architected 安全參考架構指南和最佳安全實踐。AWS 內置合作夥伴解決方案可以在您開始遷移或現代化計劃時獲得正確的雲開發構建塊，從而為您節省寶貴的時間和資源。AWS 內置解決方案還可以自動執行部署，並將安裝時間從數月或數週減少到一天。客戶經常向我們的合作夥伴尋求創新並幫助“正確使用雲”。現在，擁有 AWS 內置解決方案的合作夥伴可以幫助您提高效率，並推動合作夥伴軟件和 AWS 原生服務的業務價值。
• AWS 網絡保險合作夥伴— AWS 與領先的網絡保險合作夥伴合作，幫助簡化獲得網絡保險的流程。現在，您可以直接從經過驗證的 AWS 網絡保險合作夥伴那裡尋找和購買網絡保險，從而降低業務風險。為了減少文書工作量並節省時間，請從AWS Security Hub下載並共享您的AWS 基礎安全最佳實踐標準詳細報告並與您選擇的 AWS 網絡保險合作夥伴共享該報告。通過經過 AWS 審查的網絡保險合作夥伴，您可以確信這些保險公司了解 AWS 安全狀況並根據最新的 AWS 安全最佳實踐評估您的環境。現在，您只需兩個工作日即可獲得完整的網絡保險報價。
• AWS 全球合作夥伴安全計劃—通過 AWS 全球合作夥伴安全計劃，AWS 將利用我們全球系統集成商 (GSI) 合作夥伴的能力、規模和深厚的安全知識，共同開發端到端安全解決方案和託管服務。
• Amazon Detective 發現組— Amazon Detective擴展了其發現組功能，除了Amazon GuardDuty之外還包括 Amazon Inspector 發現結果發現。通過使用機器學習，這一發現組功能的擴展顯著簡化了調查過程，減少了所花費的時間，並有助於更好地識別安全事件的根本原因。通過對 Amazon Inspector 和 GuardDuty 的結果進行分組，您可以使用 Detective 來回答難題，例如“此 EC2 實例是否因漏洞而受到損害？” 或者“GuardDuty 的這一發現是否是由於意外的網絡暴露造成的？” 此外，Detective 將確定的發現及其相應的策略、技術和程序映射到 MITRE ATT&CK 框架，從而提高安全措施的整體有效性和一致性。
• [預告]適用於 Active Directory 的 AWS 私有證書頒發機構連接器 – AWS Private CA即將推出適用於 Active Directory (AD) 的連接器。AD 連接器將通過完全託管的無服務器解決方案幫助減少前期公鑰基礎設施 (PKI) 投資和持續維護成本。這項新功能將通過使用高度安全的硬件安全模塊 (HSM) 支持的 AWS 私有 CA 替換本地證書頒發機構來幫助降低 PKI 複雜性。您將能夠使用自動註冊功能自動部署證書到本地 AD 和適用於Microsoft Active Directory 的AWS Directory Service 。
• AWS 支付加密—在 re:Inforce 的前一天， AWS 支付加密正式發布。該服務簡化了雲託管支付應用程序中的加密操作。AWS 支付加密技術可根據各種 PCI 標準簡化您對用於保護支付處理中的數據和操作的加密功能和密鑰管理的實施。
• AWS WAF Fraud Control 推出賬戶創建欺詐預防功能— AWS WAF Fraud Control 宣布推出賬戶創建欺詐預防功能，這是一種針對 AWS WAF 的託管保護，旨在防止創建虛假或欺詐賬戶。欺詐者利用虛假賬戶發起活動，例如濫用促銷和註冊獎金、冒充合法用戶以及實施網絡釣魚策略。帳戶創建欺詐預防允許您持續監控異常數字活動的請求，並根據請求標識符和行為分析自動阻止可疑請求，從而幫助保護您的帳戶註冊或註冊頁面。
• AWS Security Hub 自動化規則— AWS Security Hub 是一項云安全態勢管理服務，可執行安全最佳實踐檢查、聚合警報並促進自動修復，現在具有近實時自動更新或抑制發現結果的功能。您現在可以使用自動化規則自動更新結果中的各個字段、隱藏結果、更新結果嚴重性和工作流程狀態、添加註釋等。
• Amazon S3 宣布推出雙層服務器端加密— Amazon S3 是唯一一個您可以在對象級別應用兩層加密並控制用於兩層的數據密鑰的雲對象存儲服務。使用AWS Key Management Service (DSSE-KMS)中存儲的密鑰進行雙層服務器端加密旨在遵守國家安全局國家安全系統政策委員會 (CNSSP) 15，以實現 FIPS 合規性和靜態數據功能包 ( DAR CP）兩層MFS U/00/814670-15 商業國家安全算法(CNSA) 加密的5.0 版指南。
• AWS CloudTrail Lake 儀表板— AWS CloudTrail Lake 是一個託管數據湖，可讓組織聚合、永久存儲、可視化和查詢其審核和安全日誌，宣布全面推出 CloudTrail Lake 儀表板。CloudTrail Lake 儀表板直接在 CloudTrail 控制台中提供來自審計和安全數據的開箱即用的可視化和關鍵趨勢圖表。它還可以靈活地深入了解其他詳細信息（例如特定用戶活動），以便使用 CloudTrail Lake SQL 查詢進行進一步分析和調查。
• AWS Well-Architected Profiles — AWS Well-Architected 引入了 Profiles，讓您可以根據業務目標定制 Well-Architected 評論。此功能創建了一種持續改進的機制，鼓勵您首先考慮特定目標來審查您的工作負載，然後完成其餘的 Well-Architected 審查問題。

ref : https://aws.amazon.com/tw/blogs/security/aws-reinforce-2023-key-announcements-and-session-highlights/

[AWS] Security Hub 推出一項新功能，可自動執行更新結果

  Written by: AWS Community Builder Wang Sheng Hau AWS Security Hub 在全球範圍內推出，在讓您全面了解 AWS 帳戶的安全狀況。借助 Security Hub，您可以在一個位置聚合、組織來自多個 AWS 服務（包括 Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Firewall Manager、AWS Systems Manager Patch Manager、AWS Config）的安全警報或結果並確定其優先級、AWS Health 和 AWS Identity and Access Management (IAM) 訪問分析器，以及超過 65 個 AWS 合作夥伴網路 (APN) 解決方案。

以前，Security Hub 可以對發現的結果採取自動操作，但這需要轉到 Amazon EventBridge 控制台或 API、創建 EventBridge 規則，然後構建 AWS Lambda 函數、AWS Systems Manager Automation Runbook 或 AWS Step Functions 步驟，如下所示該規則的目標。如果您想要在管理員帳戶和主要 AWS 區域中設置這些自動操作，並在成員帳戶和連結區域中運行它們，您還需要部署正確的 IAM 權限，以使這些操作能夠跨帳戶和區域運行。設置自動化流程後，您需要維護 EventBridge 規則、Lambda 函數和 IAM 角色。此類維護可能包括升級 Lambda 版本、驗證運行效率以及檢查一切是否按預期運行。

借助 Security Hub，您現在可以使用規則自動更新結果中符合定義條件的各個字段。這允許您自動抑制結果、根據組織策略更新結果的嚴重性、更改結果的工作流程狀態以及添加註釋。當擷取結果時，自動化規則會尋找符合定義條件的結果，並更新其中指定字段的結果。例如，如果發現的帳戶 ID 屬於已知的關鍵業務帳戶，用戶可以創建一個規則，自動將發現的嚴重性設置為「嚴重」。用戶還可以自動抑制帳戶中特定控制的發現，其中該發現代表可接受的風險。

借助自動化規則，Security Hub 為您提供了一種直接從 Security Hub 控制台和 API 構建自動化的簡化方法。這減少了雲安全和 DevOps 工程師的重複工作，同時可以縮短平均響應時間。

原文中透過兩個情境來告訴大家,怎麼透過自動化幫助減少您的團隊重複性任務

Scenario 1: Elevate finding severity for specific controls based on account IDs

Scenario 2: Change the finding severity to high if a resource is important, based on resource tags

原文 : https://aws.amazon.com/tw/blogs/security/aws-security-hub-launches-a-new-capability-for-automating-actions-to-update-findings/

[AWS] AWS 黑洞 是什麼 ？

 Written by: AWS Community Builder Wang Sheng Hau

AWS (Amazon Web Services) 的網路中，"AWS 黑洞" 是指一種異常狀態，當出現這種狀態時，特定的流量或數據包將無法正確地到達其目的地，似乎消失在 AWS 網路中，就像被吸入一個無法到達的黑洞一樣。這種情況可能導致服務的可用性下降，影響應用程序的正常運作。

AWS 黑洞通常是由以下原因之一造成的：

1. 路由錯誤：AWS 網路中的路由配置錯誤可能導致流量無法正確路由到目標。這可能是由於不正確的路由表、錯誤的網路設定或網絡設備故障引起的。
2. 安全群組或防火牆配置：AWS 安全群組或防火牆的不正確配置可能導致特定的流量被阻擋或過濾掉。這可能發生在入站或出站規則設定不當的情況下。
3. 網路連接故障：AWS 網絡連接的故障或問題可能導致某些數據包丟失或無法傳輸到目標。這可能涉及到物理連接問題、網路設備故障或 AWS 網路基礎設施的問題。
4. DDOS 攻擊：大規模的分散式拒絕服務（DDoS）攻擊可能會導致流量集中到特定的目標，使其無法處理正常流量，造成黑洞狀態。

當遇到 AWS 黑洞時，您可以開始檢查與網路相關的配置、路由、安全群組和網路連接。AWS 提供了一些工具和服務，如 CloudWatch、VPC Flow Logs 和 Network Load Balancer，可以幫助您監視和診斷網路問題。

避免 AWS 黑洞的發生，您可以採取以下預防措施：

1. 正確配置和監控路由：確保在 AWS 網路中正確配置和管理路由表。定期檢查路由配置，確保流量能夠正確路由到目標。同時，使用 AWS 提供的監控工具（如 CloudWatch）即時監控路由表和網路流量。
2. 合理配置安全群組和防火牆：正確配置安全群組和防火牆規則，確保允許預期的流量通過，並防止非法訪問。審查和更新安全群組規則，確保正確控制入站和出站流量。
3. 定期檢查網路連線和設備：定期檢查 AWS 網路連線和相關設備的健康狀態。確保物理連線穩定，並監控網路設備的運作狀況。及時處理任何網路連線故障或設備問題。
4. 實施適當的 DDoS 防護措施：考慮使用 AWS 提供的 DDoS 防護服務，如 AWS Shield，以保護您的應用程式免受大規模 DDoS 攻擊。這些服務可以幫助過濾惡意流量，保持服務的可用性。
5. 備份和災難恢復策略：實施定期備份和災難恢復策略，以便在發生黑洞或其他網路故障時能夠快速恢復服務。備份資料並驗證恢復程序。

[1] https://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/patterns/preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.html

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Verified Permissions [Preview] (EP5)

 Written by: AWS Community Builder Wang Sheng Hau

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

感謝大家收看到最後,這是這次介紹 re:Invent Security 類別最後的一項服務了

也是 Preview 版本的服務,就是 AWS Verified Permissions

大家都知道 Permission 是什麼嗎 ？

權限許可是賦予應用程式可以做什麼事情,不能做什麼事情,執行的操作的一組規則

應用程式中的權限可以基於多種因素，包括委託人的角色和屬性、資源數據以及其他上下文的訊息，例如身份驗證方法。 

通過使用基於策略的權限，您可以將授權邏輯與您的應用程式進行分離，獲得更好可見性和可審計性的訪問規則，並大規模管理權限。

Permission can be experessed as policies
權限可以表示為策略
Permit:允許 Forbid:禁止

Amazon Verified Permissions (精細授權)

協助您在自己建置部署的應用程式 (如 HR 系統和銀行應用程式) 資源中實施精細授權。
藉由 Amazon Verified Permissions，您可以執行以下任務：

定義以政策為基礎的存取模型。該模型描述您的應用程式管理的資源，以及使用者可以在這些資源上執行的動作，例如：檢視、更新和分享。

讓應用程式使用者能夠管理這些資源的存取權。該應用程式為專家們建立許可，能夠檢視和分享記錄，並將內容儲存於 Amazon Verified Permissions。
實施這些許可。

該圖顯示使用 Amazon Verified Permissions 的過程。

左邊的第一個方塊代表 Amazon Verified Permissions 服務。說明該服務提供 管理、評估和稽核應用程式存取的精細許可和授權。可以看到他會去 定義 開發人員應用程式的政策為依據作為授權模型

第二個主要步驟是在講為「管理和控管政策」。 「擁有者管理應用程式資源的精細許可。」 

第三個主要步驟標題為「授權存取」。 

問：我為什麼該選擇 Amazon Verified Permissions？

搭配使用 Amazon Verified Permissions 和 Amazon Cognito 等身分提供者，為應用程式提供更動態，且以政策為基礎的存取管理解決方案。您可以建置應用程式，協助終端使用者分享資訊與協作，同時確保資料的安全性、保密性和隱私。Amazon Verified Permissions 協助您更快速建置應用程式。也透過精細授權系統實施根據您身分角色與資源屬性的存取權，進而協助您降低營運成本。您可以自行定義政策模型，在一個集中位置建立和存放政策，並立即評估存取要求。Amazon Verified Permissions 是一款政策引擎，能夠協助您的應用程式如零信任所要求，即時驗證使用者動作。此服務提供稽核工具，以在多個應用程式中設定、維護和分析許可。

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Clean Rooms [Preview] (EP4)

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

第四個產品也還在 Preview 版本的產品

AWS Clean Rooms (安全協作的整潔乾淨室)是一項新服務，協助客戶及其合作夥伴更加輕鬆而安全地進行配對、分析和協作其組合資料集，而無需共用或洩露基礎資料。

按幾下就能打造您自己的潔淨室、新增參與者並開始協作。

利用潔淨室的各種可配置資料存取控制來保護基礎資料。
使用靈活且容易配置的分析規則，針對您具體的業務需求定製查詢。
AWS Clean Rooms為保護敏感資料，提供一組內建的數據存取控制，包括查詢控制、輸出限制、日誌和加密運算工具。

優勢:

• 多方作業 (最多可達五位資料協作者)
• 無需在 AWS 環境外維護資料複本即可進行協作 (最少的數據移動)
• 完整的程式設計式存取 (查詢控制和執行)
• 密碼編譯運算 (加密計算)
• 執行符合自動分析規則的靈活 SQL 查詢 (編程訪問)
• 此服務可以獨立購買

該圖包含五個主要步驟。

• 第一步，顯示協作成員，所有協作成員都可以貢獻純文字、雜湊或預加密資料。
• 第二步，為 AWS Clean Rooms，在不洩露原始資料的情況下與多方協作。
• 第三步，包括關聯資料表以使用來自 Amazon S3 的現有記錄，設定分析規則以使用精細、靈活的規則來控制可以執行的查詢類型，設定輸出約束以管理具有列級輸出約束的查詢結果中的分段精細度，以及執行聯合資料分析以連接並分析加密或純文字資料，從而取得業務洞見。
• 第四步，為Amazon S3，在指定的 S3 儲存貯體中接收結果。
• 第五步，則將資料另外儲存到 AWS 去做分析利用：如 Amazon QuickSight、Amazon SageMaker 和 Amazon Redshift。

使用 AWS Clean Rooms，客戶可以輕鬆地與其他正使用AWS的公司合作，無需將數據遷移出AWS環境或轉載至其他平台。

當客戶進行查詢時，AWS Clean Rooms 會在數據所在的位置讀取數據，並應用內建分析規則保持對數據的控制。

此外，AWS Clean Rooms 提供多種可配置的數據存取控制，包含查詢控制、輸出限制和日誌，允許公司自行定義各參與方的查詢限制。

AWS Clean Rooms 也包含高階加密運算工具，即使在查詢時也能保持數據加密，以符合嚴謹的數據治理政策。

由您控制誰可以參與您的 AWS Clean Rooms 協作，以及誰可以建立協作或受邀加入協作。協作中每個人的參與都公開透明，但無法在建立協作後新增新帳戶。

不過，您可以在必要時為不同客戶或合作夥伴設定新協作。由您建立和管理對您內容的存取，並透過您控管的使用者、群組、許可和憑證設定對 AWS 服務和資源的存取。

AWS Clean Rooms，您不再需要將自己的資料複本儲存在 AWS 環境以外的地方並傳送給另一方，就能執行消費者洞察、行銷測量、預測或風險評估等分析。AWS Clean Rooms 可讓您透過分析規則組態，限制可以在資料表上執行的查詢種類，從而協助您保護資料。AWS Clean Rooms 將支援兩種類型的分析規則：彙總和條列。您可以使用彙總分析規則設定資料表，以便僅允許進行只會產生彙總統計資料的查詢 (例如行銷活動測量或歸因)。您可以使用條列分析規則設定資料表，讓查詢僅分析您資料集與成員可查詢資料集的交集。AWS Clean Rooms 也將提供 Cryptographic Computing for Clean Rooms (C3R)，一種可協助您在協作期間加密敏感資料的工具

問 : 我可以查看協作成員正在對我的資料進行哪些查詢嗎？可以。您將能夠設定 AWS Clean Rooms 在 Amazon CloudWatch Logs 中發佈查詢日誌。

AWS Clean Room 加密與分析規則可讓您對想要分享的資訊類型進行精細控管。身為資料協作者，由您負責評估每次協作的風險，包括重新識別身分的風險，以及自行進行額外的盡職調查來確保符合任何資料隱私權法律。若共用的資料具有敏感性或受到管制，我們建議您也運用合適的法律合約與稽核機制，進一步降低隱私權風險。

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Inspector (EP3)

現在來介紹第三個 Securitry 的產品 Inspector

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

Inspector (中文叫檢查員)

是一種自動化的漏洞管理服務

可以持續掃描 EC2、Lambda 和 容器工作負載 以查找軟體漏洞和意外的網路暴露的風險。

使用高度準確的 Inspector 風險評分，有效地確定漏洞修復的優先級

並搭配 Amazon EventBridge 和 AWS Security Hub 整合，減少修復漏洞平均時間 (MTTR) 並簡化工作流程。

1. 近乎實時地管理漏洞
2. 適用於所有計算類型的綜合解決方案
3. 自動修補補丁
4. 無摩擦激活和管理
5. 持續漏洞監控
6. 優先和背景化的結果

Amazon Inspector 只需單一步驟，即可跨所有帳戶部署 Amazon Inspector，從而消除與部署和設定漏洞管理解決方案關聯的營運開銷。
使用 Inspector 的第一步是為您的賬戶或整個 AWS Organizations啟用它。
啟用後，Inspector 會自動掃描所選賬戶中的功能。
Inspector 是原生 AWS 服務；這意味著您不需要在您的函數或層中安裝庫或代理來使其工作。

Inspector 可以做到
自動發現和持續掃描，提供近乎即時的漏洞問題清單
透過設定委派管理員 (DA) 帳戶集中管理、設定和檢視所有組織帳戶的問題清單
每個問題清單的高度情境化和有意義的 Inspector 風險評分，可協助您設定更準確的回應優先級
直覺化的 Amazon Inspector 涵蓋指標儀表板，包括帳戶、Amazon EC2 執行個體、Lambda 函數，以及 Amazon Inspector 主動掃描的 Amazon Elastic Container Registry (ECR) 儲存庫
與 AWS Security Hub 和 Amazon EventBridge 整合以自動化工作流程和票證路由

你所使用的 AWS 服務是否需要任何代理才能使用 Amazon Inspector？
這取決於您要掃描的資源。Amazon EC2 執行個體的漏洞掃描需要 AWS Systems Manager Agent (SSM Agent)。Amazon EC2 執行個體的網路可連線性和容器映像的漏洞掃描，或 Lambda 函數的漏洞掃描不需要代理

幾個月前的 Log4j 漏洞就是一個很好的例子，表明僅在部署之前掃描函數中的漏洞是不夠的。
由於新漏洞隨時可能出現，因此當新漏洞發佈時，對工作負載進行持續監控和近乎實時的重新掃描對於應用程序的安全非常重要。
Amazon Inspector 即日起可用於使用 Java、NodeJS 和 Python 編寫的函數和層。
默認情況下，它會持續掃描您帳戶中的所有函數，但如果您想排除特定的 Lambda 函數，您可以將標籤附加到鍵InspectorExclusion和值中LambdaStandardScanning。
Amazon Inspector 最初在部署時掃描函數和層，並在工作負載發生變化時自動重新掃描它們，例如，更新 Lambda 函數或發布新漏洞CVE) 時。

除了函數之外，Amazon Inspector 還會掃描您的 Lambda 層
但是，它只掃描函數中使用的特定層版本。
如果圖層或圖層版本未被任何函數使用，則不會對其進行分析。
您可以在按 Lambda 函數篩選的 Amazon Inspector Findings 控制台中查看不同函數的結果。
當 Amazon Inspector 發現某些內容時，所有發現都會路由到AWS Security Hub和Amazon EventBridge，以便您可以構建自動化工作流程，例如向開發人員或系統管理員發送通知。

請問是否必須啟用特定的掃描類型 (即 Amazon EC2 掃描、Lambda 函數掃描或 Amazon ECR 容器映像掃描)？
如果您是第一次啟動 Amazon Inspector，預設會啟用所有掃描類型，包括 EC2 掃描、Lambda 掃描和 Amazon ECR 容器映像掃描。然而，您可以在組織的所有帳戶中停用其中任何一個或所有這些掃描。現有使用者可以在 Amazon Inspector 主控台中，或透過使用 Amazon Inspector API 來啟用新功能。

對於 Lambda 函數：主動掃描 所有新的 Lambda 函數在探索時都會進行初步評估，並在 Lambda 函數更新或發佈新 CVE 時不斷重新評估

問：如果 Lambda 函數有多個版本，Amazon Inspector 會評估哪個版本？Amazon Inspector 只會持續監控和評估 $LATEST 版本。只會針對最新版本繼續自動重新掃描，因此只會針對最新版本產生新的問題清單。在主控台中，您可以從下拉式清單中選擇版本來查看任何版本的問題清單。

問：是否需要任何代理才能使用 Amazon Inspector？

這取決於您要掃描的資源。Amazon EC2 執行個體的漏洞掃描需要 AWS Systems Manager Agent (SSM Agent)。Amazon EC2 執行個體的網路可連線性和容器映像的漏洞掃描，或 Lambda 函數的漏洞掃描不需要代理。

Amazon Inspector 對 AWS Lambda 函數和層的支持現已在美國東部（俄亥俄）、美國東部（弗吉尼亞北部）、美國西部（加利福尼亞北部）、美國西部（俄勒岡）、亞太地區（香港）全面推出、亞太地區（孟買）、亞太地區（首爾）、亞太地區（新加坡）、亞太地區（悉尼）、亞太地區（東京）、加拿大（中部）、歐洲（法蘭克福）、歐洲（愛爾蘭）、歐洲（倫敦） 、歐洲（米蘭）、歐洲（巴黎）、歐洲（斯德哥爾摩）、中東（巴林）、南美洲（聖保羅）。

[AWS] AWS Cost Management Budget 告警設定

 筆記一下最近遇到的問題, Account 上遇到帳務的問題,前後來回跟 Support 周旋了很久

剛好檢視到沒有啟用 Cost Management Budget 的設定,這邊強烈建議大家先把這個功能啟用

因為可以設定你 Account 每個月使用了多少錢,超過多少錢就會發出告警 Alert

這邊要做的就是設定你的金額閥,這樣就可以避免超用的問題

設定步驟,請參閱 AWS Cost Management Create Budget 頁面

1.進到 AWS Console 後

2.搜尋 Cost Management

3.點選左邊的 Budgets 進行設定

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Security Lake [Preview] (EP2)

 在前一篇 EP1 介紹了, AWS Macie 這個服務

接下來來介紹下一個產品 AWS Security Lake ,但還在 Preview 階段

什麼是 Preview 階段,可參考這篇說明

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

Amazon Security Lake 是一個可將組織中安全資料的來源作彙總、以及標準化和資料管理自動化，並儲存在帳戶的安全資料湖中。
安全資料湖可透過設定的安全分析解決方案來廣泛存取組織的安全資料，以支援威脅偵測、調查和事件回應等使用的情境。
Security Lake 採用開放式網路安全架構框架 (OCSF)，將AWS 安全相關的服務如AWS CloudTrail 與 Amazon GuardDuty 所記錄起來的日誌，以及其他資安合作夥伴，
如PaloAlto與IBM等所蒐集到資料，全部集中到AWS Security Lake；同時也整合分析的工具，如AWS OpenSearch、Amazon Athena等，將蒐集到的日誌資料進行資安分析，更全面地了解整個組織的安全性。

優勢

1. 自動集中來自雲、本地和跨區域自定義安全源的資安分析數據
2. 可優化和管理安全數據以獲得更高效能更高效益的存儲和查詢性能
3. 將所收集到的數據規範為做行業標準化，以便輕鬆地與多種分析工具共享和使用
4. 同時保留對安全數據的控制和所有權

Security Lake 的運作流程

Security Lake 自動將來自雲端、內部部署和自訂來源的安全資料集中儲存到帳戶中專用的資料湖。

並會將收集到的日誌儲存到您的 S3 內，讓你始終掌控並享有資料擁有權。

藉助 Security Lake，可以更全面地了解整個組織的安全資料。還可以改進對工作負載、應用程式和資料的保護。

Amazon Security Lake 的主要功能，會自動收集包括 AWS Route 53、S3 和 Lambda，以及 Security Hub 來自 GuardDuty、Macie 與 Health Dashboard 的日誌和事件來源，

另外，超過50個第三方安全調查結果，也能夠整合到 Security Lake 中，AWS安全合作夥伴可以直接將資料，透過OCSF（Open Cybersecurity Schema Framework）標準格式發送至Security Lake。

Security Lake 分析安全資料，可更全面地了解整個組織的安全性。也可以來助您改善工作負載、應用程式和資料的保護。

安全相關資料包括服務和應用程式日誌、安全提醒以及威脅情報 (例如已知的惡意 IP 地址)，

這些資料是偵測、調查和補救安全事件的真實來源。安全最佳實務需要有效的日誌和安全事件資料管理程序。

Security Lake 可將此程序自動化，並促進解決方案執行串流分析偵測、時間序列分析、使用者和實體行為分析 (UEBA)、安全協同運作和補救 (SOAR)，以及事件回應。

Amazon Security Lake預覽版已經在多個AWS地區上線，包括美東、美西、歐洲，亞太則有東京和雪梨地區。

Security Lake 可以用於你的 AWS Org 去管理你的 Account

選擇一個委託管理員帳戶來管理您的安全數據

也可以去蒐集所有的 Log 像是 CloudTrail , VPC flow log , WAF , DNS 等等的 Log 或是事件
也可以收集單一的 Region,或是多個 Region , 最後你可以選擇收整個 Org 下面的所有 Account 或是單一 Account

SecurityLake能夠自動對傳入的日誌資料建立分割區，並將其轉換成能夠高效儲存和查詢的 Parquet 或 OCSF 格式，促使資料更廣泛安全地分析。管理人員還能夠控制 Security Lake 訂閱者的資料存取層級，遵守資料留存法規要求。

目前已經整合許多第三方資料來源和訂閱服務，支援 OCSF 安全資料的第三方來源包括 Cisco、Palo Alto Networks 和 VMware 等，而支援的第三方自動化分析工具則包含 Datadog、IBM 與 Splunk等

因為支援第三方的分析工具,如畫面上的 Splunk. IBM. Datadog 等等都可以整合到 Security Lake 內做統一管理及查看對於控管上面又更為便利

補充說明:這邊如何跟第三方分析工具作整合,會在 IAM 開一個帳號給Security Lake 去抓取如 Splunk 的權限,在透過 AWS Glue 的爬蟲功能去抓取資料

在 Splunk 或是其他第三方工具中在開啟給這個 aws iam account 權限讓他可以進去撈取即可

Amazon Security Lake 採用 OCSF，這是一種開放標準，有助於從透過 AWS Security Hub 的 50 多項解決方案自動標準化安全問題清單。還有越來越多的技術解決方案可提供 OCSF 格式的資料，並與 Amazon Security Lake 整合。

什麼是 OCSF (開放式網路安全結構描述架構) (Open Cybersecurity Schema Framework)？

OSCF 是用於安全日誌和事件的協作式開放原始碼結構描述。

• OSCF 包含與廠商無關的資料分類法，可減少在各種產品、服務和開放原始碼工具之間標準化安全日誌和事件資料的需求。
• 開源項目為安全數據提供簡化且與供應商無關的分類法
• 無需耗時的前期規範化任務即可加速數據攝取和分析
• 結合來自 OCSF 兼容來源的數據，以打破阻礙安全團隊發展的數據孤島
• 可在任何環境、應用程序或解決方案提供商中採用的開放標準

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Macie (EP1)

雖然已經 2023 年了，補一下去年的年度大事，在 AWS 全球年度最大的雲端科技發表會 re:Invent 於 2022/12/2 日在美國拉斯維加斯精彩落幕，現場和線上超過五萬人齊聚一堂 , 在這次的 re:Ivent 更發佈了 13大類以及超過 70 項新服務。

本次我代表公司(iKala)與 AWS Community Hero：Ernest Chiang 一同製作、編審此份懶人包
可參考連結免費 下載 ,也於 12/28 完成 iKala x AWS re:Cap 的活動頁面

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

Amazon Macie 是一個數據資料安全和維護資料隱私的服務

是使用機器學習 (ML)和模式匹配所發現敏感數據、並提供對數據安全風險的可見性，並實現針對這些風險的自動保護管理服務。

Macie 採用機器學習和模式的比對，以更符合成本效益的方式進行大規模掃描敏感資料。

Macie 可自動偵測龐大的數據內容，且不斷擴展的敏感資料進行分類清單，包括個人識別資訊 (PII)，例如姓名、地址和信用卡號。

還提供 Amazon S3 中儲存資料的持續可見性和資料隱私權。

在 AWS 管理主控台中按一下滑鼠或透過單一 API 呼叫，即可輕鬆完成 Macie 的設定。

支援多帳戶支援以及與 AWS Organizations 的整合

在多帳戶組態中，單一 Macie 管理員帳戶可以管理所有成員帳戶，包括建立和管理各帳戶的敏感資料探索任務。

Macie 可透過 AWS Organizations 整合，支援多個帳戶。

安全和機敏資料探索結果會在 Macie 管理員帳戶中進行彙整，然後傳送到 Amazon CloudWatch Events。

現在只要使用一個帳戶，就能與事件管理、工作流程和票證系統整合，或者搭配使用 Macie 探索結果與 AWS Step Functions服務，自動執行修正動作。

本次 re:Ivent 推出的新功能是在，對S3 進行自動機敏數據偵測。 

借助這項新功能，Macie 可以自動且智能地對 S3 存儲桶中的對象進行採樣和分析，檢查它們是否存在敏感數據，例如個人身份信息 (PII)、財務數據和 AWS 憑證。 

然後顯示在 S3 中的所有敏感數據都會在有啟用 Macie 的帳戶中顯示，並為每個存儲桶提供敏感度分數。 

Amazon Macie 使用多種自動化技術，包括按存儲桶名稱、文件類型和前綴等屬性進行資源集群，以最大限度地減少發現 S3 存儲桶中機敏數據所需的數據掃描。 

這有助於您在無需手動配置的情況下持續識別和修復數據安全風險，並降低監控和響應數據安全風險的成本。

只需在 AWS 管理控制台中單擊一下或通過一次 API 調用，即可快速輕鬆地開始使用 Amazon Macie。 

Macie 使用 AWS Organizations 提供多賬戶支持，這讓您可以更輕鬆地跨所有 AWS 賬戶啟用 Macie。 

Macie 應用機器學習和模式匹配技術來自動識別敏感數據並提醒您注意敏感數據，例如姓名、地址、信用卡號或憑證材料。

現有 Macie 賬戶可免費使用前 30 天的自動敏感數據發現。在試用期間，可以在試用期結束後在 Macie 管理控制台中查看運行自動敏感數據發現的預估成本。

透過這項功能,就可以在 Findings 這個頁面內看到個風險等級的漏洞

會告訴你在哪一個 bucket 內的哪一個檔案有高風險都可以在 Macie 的這個新服務內一目了然

更為方便的管理,尤其是可以透過 Org 做跨帳號的統整可以看到旗下的所有bucket 內是否有風險產生

[AWS] AWS Migration Strategies (7 Rs) 7R搬遷策略

 AWS 7 Rs 遷移策略

Rehost

這種方案對於企業用戶而言是最容易實現, 利用 AWS 工具輕易遷移完成, 雖然不能完全發揮AWS雲端優勢, 能讓技術人力短缺的企業用戶快速遷移.

Replatform

這種方案需要經過一些優化或是修改套件後進行遷移, 不需要修改程式碼和開發新的程式, 例如現有的 MySQL 資料庫轉移上 RDS 或升級到 Amazon Auroea.

Repurchase

顧名思義就是重新購買, 完全捨棄舊有的軟體, 終止 license 續約, 進而使用新的軟體取代, 可能會遇到新軟體上的學習過程及費用的成長, 但以長期來看會有良好的效益.

Refactor/Re-architect

這種方案需要重新編寫程式碼, 符合雲端服務環境, 這種方案適合企業服務需要加速服務表現, 增加彈性或是地端上無法實現的新功能, 重新建構服務最企業相對有利, 但是會花費大量成本.

Retire

這種方案用來檢視所有服務, 有些古老的軟體環境不一定適合雲端平台, 或是不符使用, 可以藉此機會淘汰.

Retain

有一些服務結束後不再繼續使用, 但是目前還是需要運行, 如果決定不需要再使用這些服務, 就不需要遷移, 結束後直接停用即可.

Relocate 

不需要購買新的硬體, 修改或重寫APP即可搬遷至雲端上, 此方案限定於使用 VMware Cloud on AWS. 可以搭配使用 VMware Cloud Foundation 技術來遷移您設備. 

[1] 評估移轉至AWS雲端期間要淘汰之應用程式的最佳做法

[AWS] GWS User AD Join to Login AWS Account

最近剛好做到一個 Case,客戶是使用 GWS AD Account
有同時使用 GCP & AWS Service,但 IT 想統一 Account 去做管理

此步驟獻給類似需求情境的管理員們,同樣的 AzureAD 也是類似方法

Step1. 登入 要加入的 GWS Admin 管理介面

A. 選擇 Security > Authentication > SSO with SAML applications.

B. 拉到最下面, Download Metada

 Step2. 新增 IAM SAML Identity Provider 在 AWS Account

A. 首先登入想加入的 AWS Account 的 IAM Service

B. 並點選 IAM Service 下的 Identity Providers

C. 點選右邊 Add Provider

D. 點選 SAML

E. Provider Name (自行輸入,這邊是輸入 Join 的 GWS Domain)

F. Medata document (把剛剛在 GWS 端下載的檔案上傳上來)

G. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

Step3. 新增 AWS IAM Role 給予 透過 Identity Provider 的 GWS Account 權限 

A. 進入 IAM Console,選擇 Role > Create Role

B. 選擇 SAML 2.0 federation 下拉選單會帶出剛建立的 Provider

C. 然後點選 Allow programmatic and AWS Management Console Access

D. 點選 Next : Permissions 

E. 通過篩選把 AWS 預設 Role 帶出

F. 點選 左上方 放大鏡符號

G. 選取 Type > AWS managed – job function

H. 選擇 PowerUserAcces 後,點選下一步

I. Role details 輸入 Role 名稱 (GoogleSAMLPowerUserRole)

J. Description 輸入 Role 的大概內容 (GWS Login PowerUser Role)

K. 拉到最底,點選 Create Role

L. 建好後會看到你新建的 Role

M. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

N. 如需新增其他 Role ,重覆 Step 3 所有步驟即可即可

•  Role 1 GoogleSAMLPowerUserRole_Login
  • arn:aws:iam::174XXXXXXXXX:role/GoogleSAMLPowerUserRole_Login

 Step4. 給予 GWS User AWS IAM Role

A. 回到 GWS Admin Console

B. 點選 Directory > Users > More Option > Manage custom attributes

C. Category: AWS
        Description: Amazon Web Services Role Mapping
D. Custom fields, enter the following values:
        Name: AssumeRoleWithSaml
        Info type : Text
        Visibility : Visable to user and admin

        InNo of Values : Muti-value

        E. 回到 Users 端,選擇要加入的 User Account
        F. 點選 User > User Information

        G. 移到最下面有個 AWS 的,點選編輯

        H. 這時輸入最一開始拿到的 Identitiy Providers + IAM Role ARN

                這邊要特別注意,兩個組合再一起時,中間要用 , 分開

例如 : 

arn:aws:iam:: 174XXXXXXXXX::samlprovider/Dev.Cloud.XXX.tv ”,”arn:aws:iam:: 174XXXXXXXXX:role/GoogleSAMLPowerUserRole

I. 一行是一個 Role,假設你需要給予兩個或是更多的 Role

        請依照同樣方式 Identitiy Providers,IAM Role ARN

J. 假設你有多個 AWS Account 也可以依照前面步驟

        從 Step 2 開始,在另一個 AWS Account 用同樣步驟進行

        Step 3 在另一個 AWS Account用同樣步驟進行

        Step 4 開始,但只需要從 E 項目開始把其ARN 新增至 User Information內即可

K. 可看到我同時有兩個不同AWS Account的 Providers + Role ARN

Step 5. 在 GWS 端設定 SAML Application 給 AWS Login 

A. 進到GWS Admin 管理介面
B. 點選左邊 Apps > Web and Mobile apps 

C. 選取 Add custom SAML App 

 D. App name : 輸入 AWS Login (顯示在右上角選單內的名稱)

        APP Icon : 上傳一個圖示(顯示在右上角選單內的圖示)

E. 點選下一步

        Services Provider Details

• ACS URL : https://signin.aws.amazon.com/saml
• Entity ID : urn:amazon:webservices
• Name ID format : EMAIL
• Name ID : Basic Information > Primary email

F. 點選下一步

        在 Attributes 內新增

• 項次一 AWS 選擇 AssumeRoleWithSaml
• App attributes 輸入 https://aws.amazon.com/SAML/Attributes/Role
• 項次二 Base Information 選擇 Primary email
•  App attributes 輸入
•  https://aws.amazon.com/SAML/Attributes/RoleSessionName

    G.     按下 Finish 即完成

    H.     在來回到 Web and Mobile Apps 內,點選剛新增的 SAML APP

    I.     進入 User Access 把 Service Status 開城 ON for everyone

 J. 回到上一頁,按下 TEST SAML Login 就會出現,你配置的 Domain

或是點選右上角 APP 選單,往下滑也會有你建制的 SAML APP

K. 點選後就會出現 AWS Account and 你所賦予的 Role 權限

        此 Demo 建置了兩個 AWS Account 兩個 Role

L. 依據不同的權限,不同的帳號做登入測試

 

Step 6. 查找登入 Login Log 

A. GWS 端該如何查詢 Login Log

Console > Reporting > Audit and investigation > SAML log events

 B. AWS 端該如何查詢 Login Log

AWS Console > CloudTrail > Event history