我在前面的Part 1 — Part 4介紹了AWS大數據的資料擷取，資料處理與分析，最後資料視覺化。然而若沒有好的資料安全防護，我們的核心資料就會有外洩的狀況發生。

這一篇我們會來介紹在Part 1 — Part 4中所介紹的各項AWS所提供的各項資料處理服務(AWS S3, DynamoDB, Redshift, Elasticsearch, EMR, Glue, Kinesis)的資訊安全，。從資訊安全的基本驗證(Authentication)，授權(Authorization)，加密(encryption)，到合規(Compliance)。

Shared Responsibility Model
在談到AWS的各類服務的資料安全之前，我們需要老生常談一下雲端運算的shared responsibility model。知道雲端運算的人對這個概念應該不陌生，簡單來說就是關於雲端運算的資訊安全，CSP會做好它該做的，你(客戶)也應該做好你該做的。也就是出了事先看看自己是不是自己的部分沒有做好就直接甩鍋給雲端運算平台業者。

而關於AWS的資料平台的資訊安全，一供分為六個Layer(請參考下圖)。

根據上面CSP與你要負責的模型來舉例，例如我們在AWS跑一個EC2(VM),AWS負責從Hypervisor到physical layer到機房實體安全。而你就要負責VM(OS)各項安全，包含上patch, firewall的設定，跑在上面的Applciation security等。

Security Services
security符合了絕大多數的資訊安全要求 — C.I.A(Confidentially, Integrity, and Availability)。而關於AWS各種服務的合規要求可參考AWS的Compliance resources。

提供五種方式來保護我們運行在AWS上的workload與Application。

1. Data Protection — 包含了加密，密鑰管理(key management)，與自動威脅偵測
2. Identity and Access Management(IAM) — 進行 identities/resource/ permission的管理。
3. Infrastructure Protection — 根據我們所定的規則來過濾流量來保護我們的web application。這些可以過濾的要求可以根據像 — IP 來源， HTTP header，HTTP body或URI string等。排除一些很基本的網路攻擊，如 SQL Injection or cross-site scripting.
4. Threat Detection and Continuous Monitoring — CSP 負責infrastructure，因此會持續監控雲端環境
5. account的網路活動和行為。 我們在 account中可以做什麼和不能做什麼有一定的限制。
   Compliance and Data Privacy — CSP使用我們的組織遵循的 AWS 最佳實踐和產業標準，以自動化的方式為我們提供合規狀態的完整視圖。

下表是 security, identity, 與compliance的要求下所提供的各項服務

IAM(Identity and Access Management) 概觀
提供了多種的資源，而IAM就是用來對這些資源實施存取控制。IAM被使用在authentication(誰可以登入)，與authorization(甚麼樣的服務，使用者可以存取)。

IAM User
這通常代表一個人或程式服務。IAM user會包含帳號與密碼的組合。這是最常被用在 accounts中的。而當我們第一次使用時，用email 與密碼登入的帳號稱為root account。對於我們的日常作業而言CSP強烈建議不要用root account，我們應該用root account create IAM user來進行我們的日常作業。

IAM user通常使用如下表所示的的方式來access CSP上的服務

IAM Groups
跟一般的電腦群組管理一樣，方便我們將一群IAM user分類。IAM group裡 IAM user會繼承其權限設定。但IAM Group不可以被當成 permission policy的Principal，比較簡單的方式是將這個存取政策一次attach到多個需要的IAM user中。IAM Groups有以下的特徵:

• 一個group可以有許多IAM user，一個IAM user也可以隸屬多個group
• Group裡不可以含有另一個Group(也就是沒有sub-group的概念)
• 一個account最高可以有300個Group
• 一個ccount可以有5000個user，而這5000個user可以同在一個Group

IAM Roles
IAM roles是我們可以在具有特定權限的account中建立的 IAM identity。 IAM roles類似於 IAM user，因為它是具有permissions policies的 identity，定義了這個identity在 AWS 平台上可以執行的操作。 roles與users的不同之處在於它不是與一個人（如IAM users）唯一關聯的，並且可以由可能需要它的任何人來關聯起來。 此外，與users不同的是，roles沒有諸如密碼和訪問密鑰之類的long-term credential。 相反，assuming roles將導致為roles sessions提供臨時安全憑證。

當我們使用roles時:

• 我們可以使用roles將權限 delegate給需要存取資源的人(也就是將roles attach 在IAM user)
• roles可以給於一些需要暫時性存取資源的人，例如外部使用者或程式
• Roles可以被使用在非驗證系統，例如Microsoft的AD
• Roles可以給與第三方的稽核權限來執行稽核工作

以下表格為CSP所提供不同類型的role

EMR Security
我們在Part 3介紹過 EMR cluster。不論是暫時性或長期運作的 cluster，它都運行在VPC中。而VPC可以讓我們用網路的方式進行存取控制，如private IP address ranges, subnets, routing tables, network gateways。因為EMR的底層就是EC2。我們可以將cluster放在 Public or private subnet，如果是public subnet就需要有 Internet gateway才能讓外部的人或服務連到cluster。

當我們在create cluster時，可以指定要放在哪幾個AZ中。而cluster啟動後其相對應的Security Group也開始運作。

Public Subnet
如剛剛提到的，如果我們是把cluster放在public subnet中必須要把Internet gateway attach到該subnet，這樣才可以連到其他的public endpoint服務中(如S3或DynamoDB)。但如果該AWS有提供 VPC endpoint則可以透過這種方式連結，可增強效能與安全性不用透過Internet Gateway走Internet(參考以下範例架構)。

剛剛提到EMR的底層是由EC2組成的，而知道EC2的人都知道我們是用Security group來控制進/出的網路連線。在這裡EMR提供兩種Security Group，一種是EMR代管的，一種是我們自行定義的。

EMR Managed Security Groups
如它的名字所示，這是由EMR代管的security group。這一種的security groups唯一的目的就是控制cluster內部通訊與其他 resource的通訊。如果需要讓cluster外的人或Application存取，我們可以修改該security group或增加新的。CSP在這裡強烈建議不要去修改這個代管的security groups而是去增加新的rules以免不小心更動到重要的rules接著cluster就死給你看。

其中一個代管的security groups名稱是”ClasticMapReduce-master”，這個預設好的rule讓 Ip是 any(0.0.0.0/0)透過SSH來連接。所以最佳實踐應該是我們需要過濾這個source IP。下表為EMR代管的security groups名稱

Private Subnet
private subnet與Public的不同點在於如果其他的services 有提供VPC endpoint的方式，哪它就會使用這種方式。如果該服務沒有VPC endpoint的方式來連就要需要用NAT instance或Internet Gateway來往外連。可參考以下範例架構

在 EMR的Console關於security的設定有三個，分別是 Security Configuration, VPC subnets, 與Block Public Access(如下圖)

Security Configuration
這一個設定做好後可以套用到多個cluster上。再者這裡的設定可以分為四類，分別是加密，驗證，EMRFS的AIM roles與 Lake Formation整合。

加密(Encryption)
Data at rest的加密會在 EMRFS(S3)與HDFS的data store。EMR同時耶支援Data in transit的加密。在Security configuration中的資料加密選項有: S3 encryption, local disk encryption, 與 data-in-transit encryption。

S3 加密
這是針對資料在S3中的加密，也就是 EMRFS(EMR file system)object在S3中的read/write。EMR支援以下幾種加密選擇

• SSE-3
• SSE-KMS(使用KMS的master keys來加密被加密資料的key，加密發生地在server-side)
• CSE-KMS(使用KMS的master keys來加密被加密資料的key，加密發生地在client-side)
• CSE-Customer(必須提供custom key提供location [S3 bucket和key provider class)

當我們選擇完成對要S3的bukcet做哪種加密，原來在S3上的bucket如果也有其他加密演算法的話其設定就會被EMR給覆蓋過去。而每個S3 bucket的加密方式(encryption modes and encryption materials)是可以個別選擇的。

Local Disk 加密
EMR在這裡提供了三種不同的加密

第一種: HDFS加密
HDFS不只是用來暫存資料的，同時也是會有資料從instance store volumes與EBS volumes來讀取與寫入資料的。當我們啟用 local disk加密時有幾個選項可以選擇:

1. Secure Hadoop RPC(Remote Procedure Calls) 這個設定在 core — site .xml設定檔中的 hadoop.rpc.protection 的設定中，啟用這個資料會在hadoop service與client端之間是加密的。
2. Data Encryption on HDFS Block Data Transfer 這個選項是讓我們在啟動data node的資料加密的。這個設定在 hdfs-site .xml設定檔中的 dfs.encrypt.data.transfer 把它設定為 true，它就會用 AES-256的方式加密。
3. Transparent Data Encryption on Amazon EMR 這個設定預設是沒有開啟的，需要的話要手動開啟它。這個設定是針對 HDFS encryption zone，也就是我們指定一個特定的HDFS路徑進行加密。每一個 encryption zone(也就是路徑)都會他們自己的key。EMR預設是使用 KMS的但我們也可以選擇其他的key management services。

第二種 Instance store 加密
因為EMR的底層是EC2 instance，所有的hadoop 軟體與資料都跑在上面。所以我們也可以對其instance store來加密。加密的type有兩種(如下表)

第三種 EBS volume加密
針對EBS Volume，CSP預設都是加密的。所以不管我們有沒有在EMR的啟用local disk encryption，這個預設都是有效的。不過當我們啟用local disk encryption，EBS volume的預設加密就會被EMR給取代。

下圖為我們在設定EMR上面設定S3加密與local disk encryption會看到的畫面

Data-in-transit encryption
根據EMR不同的版本提供了以下針對特定的Application 看到的加密(在security configurations頁面會看到)

1. Hadoop
   (a)使用https的方式在shuffle時加密，(b)Secure RPC calls in Hadoop，剛剛有稍微介紹過。(c)Data Encryption on Block data transfer。

2. Hbase
   從EMR 5.10.0開始我們可以開始使用Kerberose在cluster內的做驗證。詳情可以參閱CSP文件庫

3. Presto
   任何在 Presto node的內部通訊都會用SSL/TLS的方式加密。

4. Tez
   Tez是對Hive query的runtime，可以用來取代MapReduce。而當Tez要shuffle data時，它會使用TLS在hadoop node之間加密

5. Spark
   (a) Spark在components內部RPC通訊會用AES-256加密(從 EMR 5.9.0開始)

驗證(Authentication)
Security configuration允許我們使用Kerberos來做為驗證系統。它使用密鑰加密來提供強身份驗證，以便密碼或其他credentials不會以未加密的方式通過網路發送。當我們啟用使用Kerberos的驗證之後，EMR會設定其運行在Cluster內的Applications, components與subsystems這些要互相做驗證。

EMR還提供使用專用的KDC(Key Distribution Center)或也可以用外部的KDC。我們可以設定其ticket的lifetime，預設是24小時。我們也可以設定 cross-realm trust，意思是我們讓principals(通常是使用者)從不同的Kerneros來源驗證其在Cluster內的Application。這個就稱為 cross-realm trust，詳情可參閱文件庫。

EMRFS的 IAM Roles
這是我們要永久儲存EMR資料的建議選項。當EMR運作時，EMR會使用我們已經定義好的 service role(裡面已經有定好的permission)被attach到EMR的cluster來access S3。所以無論我們在上層做些甚麼。EMR都會用這個service role來access S3路徑。

不過基於上層的不同的 level的多個user對 EMRFS內的不同資料的管控，我們可以使用 IAM role(fine-grained access)的方式來實現。這個role定義的在S3裡可以做些甚麼操作。

在Security Configuration中，在”IAM roles for EMRF”選項中我們選根據不同的role對應其identifiers(user, groups, S3 prefix)，如下圖

哪麼 IAM roles在 EMRFS是如何作業的呢?
當我們定好roles mapping之後就可以對S3 make request，假如request match basis(user, group, S3 prefix)的存取，cluster中的EC2就會assume成哪一個role來進行其作業。

當接收到request時，EMRFS會由上到下檢查符合哪一個role，意思是不只role mapping的排序很重要，這個role在S3的 policies也相對重要。假如都沒有符合的，EMRFS最後就會用我們在create 這個cluster時所用的role。

Lake Formation整合
我們可以用 Lake Formation 來建立在 Glue Data Glue的fine-grained column-level 來控制使用者可以用到那些columns/rows。 Lake Formation也可以讓我們啟用對 EMR與 Apache Zeppelin的 federeated single sign-on(與 SAML相容的驗證系統)。

為了讓EMR與 Lake Formation的整合，以下條件需要被滿足

1. 我們的identities需要是以 SAML為基礎的 identity provider，像是 Active Directory Federation Service(ADFS)
2. 我們的metadata必須放在 Glue Data Catalog
3. 我們會使用 Apache Zeppelin 或EMR notebooks來access在 Glue與Lake formation的資料
4. 我們需要有操作Lake Formation的權限

Block Public Access
設定完Security Configuration之後就需要考量Public access的設定。這一個設定預設是開啟的，並且其設定是讓anywhere(0.0.0.0/0)IP可以透過SSH來連接EMR。

VPC Subnets
此一選項我們剛剛有提到，主要是將EMR cluster放在Private subnets能達到高效的網路與網路的安全性。

在建立 Cluster的安全選項
我們在建立Cluster時會看到 quick與advanced兩種選項。

在快速(Quick)選項中在Permission選擇有default與custom。Default選項是EMR已經幫我們針對EMR roles與EC2 instance profile做好的roles。其中 EC2 instance profile是用來讓底層的EC2用那些role來運作EMR上面的Application與提供access 其他服務的。而Custom則是自行定義的。

而Advanced 選項則有更多的安全選項(如下圖):

首先我們可以看到EC2 Key Pair的部分，這一個的使用方式與一般我們在連線EC2 instance的key pair是一樣的。再來是 Cluster Visible to All IAM Users in Account這一個選項，預設是勾選的。主要是讓在同一個 account中的IAM user可以看到這一個你做的Cluster出現。

Permission的部分有預設與客製的方式，剛剛有提到過了。有一個部分要提到一下，Default mode 與Advanced在這一部分只有Advanced mode會顯示到AutoScaling的roles設定，主要是當loading增加時EMR有權限執行AutoScaling的動作，在Default一樣有只是沒有show出來。Security Configuration在之前我們用很大幅的篇章提到過。EC2 Security Group我們一樣在之前有提到過。

S3 Security
S3的儲存是在AWS的主力，幾乎所有CSP的其他服務都會用到，也是建立AWS Data Lake的底層。這一段我們會就介紹S3的資料加密，對S3中的resource的access control，不同的 kuckets與files的logging與S3的保護S3資料的最佳實踐。

S3的資料存取管理
在S3中我們需要管理的resource中有, buckets, objects與其他 sub-resource，如 lifecycle configuration, website configurations與 version configuration。管理 account與 user對其resource的控制會編寫在access policy，而 Owner則有完全的控制權。Owner有權給予其他人access的權限，這都會寫在一個access policy(JSON格式)。

Access policy有兩個種類: 一種是 resource-based policies另一種是 user policies。

Resource-Based Policies
這是將Policy attach在resource(通常是bucket)上的做法。這邊分為 ACL與 bucket policy。

ACL的方式是每一個bucket與Object都有他們相對應的ACL，這基本上是一個授權列表，用於標識授予的權限以及給誰權限。ACL被用來給其他 account最基本的read/write權限與使用S3特有的 XML schema.

Bucket Policy(JSON格式)是在bucket level(包含其object)上給予其他account與IAM users權限。Bucket policies會輔助或是在某些情況下取代ACL。在Bucket policy的編寫中我們會看到四個部分並加上一個範例(如下)，分別是

• Effect: 能不能做 — Allow 或Deny，在範例中我們看到是Allow允許。
• Principal: 這通常使指User或是某個Application要access，星號代表不指定，都可以access。範例中就是用星號。
• Action: Principal能做些甚麼操作，範例中我們看到的是對Object有read permission
• Resource: 指定哪一個resource會被這個policy影響到，範例中我們看到的是analyticscertbuckts這個bucket與裡面所有的Object
  

User Policies
這是將policy attach到 IAM users, groups與roles中。以下為一個user policies範例

不管是bucket policies或User Policies都可以單獨或一起使用。當S3收到一個access request它會先查看所有的access policies來看這個request有沒有符合其中一個來給予權限，如果都沒有就會deny這個request。在Runtime時，S3 會將所有相關policies（user policies、bucket policies、ACL）轉換為一組policies進行評估，然後根據發出request的上下文進行評估。

大多數的Request都需要先經過驗證(authentication)但也有不用驗證的狀況，可能是這個bucket是公開給外面的人寫入資料，或Bucket ACL給予全部的 user group或匿名的人 寫入資料或full control狀況。但這種狀況在安全性的最佳實踐是不要有。

Resource-based policies包含了 bucket policies, bucket ACLs, Object ACLs。至於在甚麼情況下該用哪一種，AWS提供了一些範例來供我們參考。詳情可參閱 文件庫。

Blocking Public Access
這是一個account level的設定，並且是對控制我們在S3上的access point, buckets與 account來進行 public access。簡單的來說就是進行白名單管理，在create bucket時這個選項是開啟的，也就是說當一個bucket 被create後沒有人(除了owner跟root account或S3的admin)可以去access它。這個選項存在的好處是當我們對我們的bucket 不小心設定到public時，我們的這個設定就無法完成，有防呆的效果在。

但我們可以看到這一個選項底下有其四個子項可以選擇，這是根據可能有的例外狀況我們可以選擇的(如下圖)

S3的Data Protection
在S3針對Object的加密有以下四種方式

SSE-S3 : 加密的系統與key完全由S3來管控，使用者完全不用管理。
SSE-MKS: 使用MKS(Key Management Service)來管控加密的key
SSE-C : 我們要自行產生並管理加密的Key
Client side Encryption: 檔案在本地端加密好才送上S3 bucket
SSE-S3加密
加密的系統與key完全由S3來管控，並且是在server side做加密，加密法是AES-256。我們用http request傳送檔案時在 header中要告訴S3我們要加密的方式 — " x-amz-server-side-encryption”: “AES-256”

SSE-KMS加密
使用KMS加密的好處是我們可以自己控制key的管理並且可以有audit紀錄可以查閱。在http的header中要使用這樣的方式是 — “ x-amz-server-side-encryption”: “aws:kms”

但選擇這種方式有一些限制存在。但我們上傳資料時S3會對KMS 產生 GenerateDataKey的API call.而在下載時會有Decrypt的API call。這些在特定時間內會有呼叫次數的限制，根據不同的區域會有每秒 5500/1000/30000的次數限制。

SSE-C加密
這個方式是由我們自己產生與管理加密的key，而是在每次上傳檔案時把加密資料的key一起送上S3。S3會利用這個Key加密，完成後S3就會丟掉這個key不會保存它。由於每次都會把key 放在header中所以一定是使用HTTPS的方式進行傳送，每次的傳送檔案上S3的http request一定都要附上。

Client Side Encryption
檔案的加解密都需要在本地端進行

S3同時支援http and https的方式傳送資料，但https是建議的選項。

S3的Logging與 Monitoring
S3使用多種的工具監控與稽核S3的resources。分別有以下一些重要的工具

CloudWatch Alarms 這是對其S3的一些效能監控。在達到一些設定的界線之後該服務會使用AWS SNS發出通知或是使用 autoscaling policy(S3用不到這個)

CloudTrail Logs 這是察看S3的稽核紀錄，例如可以看到這個request從哪個IP來的，誰發出的request，何時發出的與其他一些額外的details。

S3 Access Logs 也是用還追蹤那些request到達S3這裡。這個logs主要用在 security audition與讓我們知道關於S3帳單的使用量等數據。這個服務本身是免費的，但產生的logs資料(放在S3 bucket)存放要收費。

Trusted Advisor 這是AWS針對我們整體在AWS上使用到的各項服務給予最佳實踐的建議，包括的安全還有較省錢的服務等級或規格建議。而針對S3的安全部分會從一些security context來判斷，包含有:

• S3 bucket的Logging configuration
• S3有開放的權限做安全檢查
• 會檢查沒有開啟版本控制或是版本控制功能暫停的bucket來檢查

S3的Security最佳實踐

• 開啟 account-level的 Block Public Access功能
• 使用access point來限制Application對其S3的權限
• 盡量使用 VPC endpoint與 access point
• 在bucket policy強制指定用 TLS
• 所有的Object都加密，特別利用 SSE-KMS與 SSE-S3方式
• 啟用 object lock, 版本控制，與MFA delete來保護重要資料
• 使用監控工具，如 CloudTrail與 AWS Config

Athena Security
Athena的存取管理
Athena一樣使用IAM來對其控管。User對Athena的操作就是run SQL query，而為了可以Run SQL query需要有以下的權限:

• Acess到Athena API actions，包含 Athena workgroups 的。
• Access到底層的storage，主要是access S3因為資料都在哪裡
• Access Glue Catalog的權限，因為metadata在哪裡

為了達成上三個要求，我們的 IAM principals需要identity-based policies。這個policies會定義那些可以操作那些不可以操作。Athena 無需user嘗試確定 Athena 需要哪些操作才能正常作業，而是提供了兩個託管policies，這些policies易於設置，並且會隨著services的發展和新功能的發布而自動更新所需的操作。 policies如下：

AmazonAthenaFullAccess
這會給予 Athena的最大權限,包含 Glue, S3, SNS, CloudWatch。這個對沒有Athena使用經驗的人是建議選項。

QuickSightAthenaAccess
這是讓QuickSight要連結Athena的人使用的。這個權限通常也包含access Glue, S3。

如果是用ODBC/JDBC來連接Athean的話使用的一樣是AWSQuickSightAthenaAccess這一個policy。剛剛提到Athena的資料存放是在S3中，所以如果不適是用託管的policy需要仔細的在客製policy中設置在S3中適切的權限。

如果我們使用適用於Athena 的 Glue Data Catalog，則可以為 Athena 中使用的DB和table定義resource-level policies。 Athena 僅在DB和table level提供fine-grained controls，而不在單一partition level提供。 此外，如果我們的 Glue Data Catalog位於不同的account中（cross-account access），則 Athena 在撰寫本文時不支持該選項。

Athena Workgroups 的存取
Athena workgroups是一種resource type，能夠在 users, 團隊或Application之間分離 query execution與query history。由於是resource所以要用resource-based policies來控制存取。

Athena的 Federated Data Access
如果我們是使用外部的驗證系統(如微軟的AD)，哪Athena也支援此種驗證方式。這需要使用 JDBC or ODBC driver搭配能支援 SAML 2.0 去access ADFS (Active Directory Federation Services)3.0並且啟用 client application去呼叫 Athena API actions。整個流程可參考以下架構圖