Security

SAS Viya (9)

教學目標

初步了解在 SAS Viya 中的驗證選項與介面的概念。

重點概念

首先我們在了解 SAS Viya 3.2 中驗證選項之前,最好先了解 SAS Viya 3.2 主要有三種部署類型,分別為:

  1. 完整部署 (Full Deployment)
  2. 僅程式操作部署 (Programming Only Deployment)
  3. 僅視窗操作部署 (Visual Only Deployment)

其中所謂完整部署主要是指包括 SAS 雲端分析服務、微服務、狀態服務和 SAS 基礎元件的完整部署。所謂僅程式操作部署主要是指不包括微服務元件的部署,此部署方式若要使用 SAS 雲端分析服務,則僅能透過 SAS Studio 和 SAS 程式碼進行 SAS 雲端分析。所謂僅視窗操作部署主要是指不包括 SAS Studio 元件的部署,此部署方式若要使用 SAS 雲端分析服務,則僅能透過 SAS Visual Analytics 等網站應用程式進行 SAS 雲端分析。

接著根據不同的部署類型,我們主要有兩種介面讓使用者存取 SAS Viya 3.2 服務,分別為程式介面驗證和視窗介面驗證,主要差別在於程式介面驗證主要是以 SAS Studio 為主,視窗介面驗證主要是以 SAS Visual Analytics 等網站應用程式為主,此外 SAS Cloud Analytics Services 還有提供 Python 介面、Java 介面和 Lua 介面進行存取驗證。

再來在 SAS Viya 3.2 中的視窗介面驗證主要是整合狀態服務和無狀態服務,也就是微服務。使用者主要會透過 SAS Logon Manager 的視窗介面進行登入,其主要是透過 HTTP 代理的方式進行存取,請注意識別的微服務必須連接 LDAP 提供者以利提供使用者和群組資訊,所謂 LDAP 提供者可以是 Microsoft Active Directory 、Open LDAP、… 等。此外我們主要有是四種驗證選項讓使用者存取 SAS Logon Manager,分別為:

  1. LDAP Provider
  2. Kerberos
  3. OAuth
  4. SAML

透過上述四種驗證選項 SAS 雲端分析服務環境將會由 SAS Logon Manger 產生內部 OAuth Token 進行執行操作,在大部份的案例中實際工作階段主要是由 CAS Server Controller 透過 cas 服務帳號啟動 CAS Session Controller 也就是啟動 SAS 雲端分析服務。

最後程式介面驗證重點在於 SAS Studio 、 SAS Object Spawner 和 SAS Workspace Server 如何存取 SAS 雲端分析服務,在 SAS Viya 3.2 中我們可以針寸 CAS 和 SAS Studio 設定主機使用可插拔驗證模組 ,同時使用 PAM 的指令存取 CAS 建立驗證資訊之檔案。此外在 SAS Viya 3.2 中的 SAS Studio 在完整部署中主要是整合 HTTP 代理,所以 SAS Viya 3.2 使用者無法直接連線 SAS Studio 網站應用程式,並且在 SAS Studio 輸入的使用者帳號和密碼不會傳送給 SAS Logon Manager 進行驗證,而是 SAS Object Spawner 使用主機中的 PAM 設定驗證使用者名稱和密碼,此時是否需要本機帳號取決於 PAM 設定和 LDAP 提供者中的帳號,請注意 SAS Object Spawner 會透過 sas 服務帳號啟動 SAS Workspace Server。此時 SAS Worksapce 除了透過使用者帳號和密碼與 LDAP 提供者進行驗證之外,還會透過使用者帳號和密碼與 SAS 雲端分析服務進驗證,同時 CAS Controller 也會透過 PAM 的設定驗證使用者憑證和啟動工作階段處理程序。

總結在 SAS Viya 3.2 中提供非常完整的身份驗證解決方案,每家企業會有專屬的身份驗證方式,此時如何在導入 SAS 解決方案時有效整合現行身份驗證的方式,將會是 SAS Viya 3.2 相較於 SAS 9 更能夠為企業組織帶來使用者單一登入與帳號密碼統一管理的效益。此外目前許多企業是採用 Windows Active Directory 進行身份驗證,此時我們僅需要在 SAS Environment Manager 中針對 Identify Service 設定下述資訊,就能夠載入Windows Active Directory 中的使用者帳號和群組資訊進行控管,當成 LDAP 提供者,但請注意某些服務必須搭配主機帳號對應才能夠正常存取使用。

1
2
3
4
5
6
7
8
9
10
11
config:
application:
sas.identities.providers.ldap.connection:
host: '<LDAP HOSTNAME>'
port: 389
userDN: '<Service Account DN>'
password: '<Service Account Password>'
sas.identities.providers.ldap.group:
baseDN: '<OU to start user search from>'
sas.identities.providers.ldap.user:
baseDN: '<OU to start group search from>'

相關資源

SAS Viya (8)

教學目標

初步了解在 SAS Viya 中針對資訊安全三個方面的應用。

重點概念

首先在 SAS Viya 中針對資訊安全主要有三個方面的應用,分別為:

  1. 驗證 (Authentication)
  2. 授權 (Authorization)
  3. 加密 (Encryption)

接著驗證主要識別使用者身份或服務帳號方面的安全,我們主要會透過下述三種模式進行驗證,分別為:

  1. 主機驗證 (Host Authentication)
  2. 直接驗證 (Direct LDAP Authentication)
  3. 雙重驗證 (Dual Authentication)

其中所謂主機驗證是指透過主機進行任何驗證機制的處理請求,當我們登入至 SAS Studio 時將會關聯 Object Spawner 要求主機驗證憑證,當驗證成功將會啟動工作站伺服器,此外當我們從 SAS Studio 中使用 CAS 服務時,則必須在 CAS 伺服器主機進行驗證。所謂直接驗證是指過 LDAP 提供者進行直接的驗證,此外針對單一登入 (Single Sign On,SSO) 也支援 IWA、OAuth 和 SAML 等機制,請注意 IWA、OAuth 和 SAML 僅能修改登入服務 SAS Logon Manager 的識別驗證機制,無法修改識別服務 Identities Service 的使用者和群組資訊,當我們登入 SAS Visual Analytics 或 SAS Environment Manager 時,則必須使用此模式進行驗證。所謂雙重驗證主要是同時使用主機驗證和直接驗證,若是 servicesBaseUrl 選項被設定時,則 CAS 需要進行雙重驗證,其中 LDAP 提供者又可分為相同提供者 (Shared Provider) 和不同提供者 (Different Provider),當我們登入 CAS Server Monitor 和從 SAS Studio 存取 CAS 服務時皆需要使用雙重驗證,此外當我們透過 SAS Visual Analytics 或 SAS Environment Manager 存取 CAS 服務時必須確認 OAuth Token 是有效才能夠正常操作。

再來授權主要是決定哪一個資源被可哪一個使用者使用,SAS Viya 授權層級主要由兩個授權系統所組成,分別為:

  1. CAS 授權系統 (CAS authorization system)
  2. 一般授權系統 (General authorization system)

其中任何系統皆使用不同的模型保護不同的資源類別,請注意初始和預設存取是被限制的,主要有五個重點,分別為:

  1. 任何未被授予的存取是被禁止的。
  2. 預先定義的物件會被預先定義的規則或存取控制所保護。
  3. 只有特定群組或角色的成員才能夠存取特權管理的功能。
  4. 使用者存取物件的管理是會被繼承、同時也能設定規則和直接設定。
  5. 一般使用者是有限的存取,僅可以存取個人資料庫和共享的資料夾。

最後加密主要是將資料轉換為無法理解的形式來進行傳輸或儲存的安全應用,分別為:

  1. 資料傳輸 (Data in Motion)
  2. 資料儲存 (Data at Rest)

其中所謂資料傳輸主要是提供 TLS 安全性,並且遵循最高的資安標準,在安裝時 SAS Viya 提供 HTTPS 安全存取的方式。所謂資料儲存主要是針對 PATH、HDFS 和 CASLIB 進行加密設定。

總結本篇主要是簡單介紹 SAS Viya 中針對資訊安全三個方面的應用,分別為驗證、授權和加密,其實也就是企業中經常提到的資訊安全之應用,分別為:

  1. 單一登入應用,也就是驗證應用。
  2. 權限控管應用,也就是授權應用。
  3. 安全連線應用,也就是加密應用。

相關資源

資料處理之相關法規 (1)

基本介紹

教學目標

銀行業的資料特性非常多元其中牽涉到大量客戶資料、公務機關查詢資料和業務機密資料,因此在資料處理時需要特別謹慎處理,除了工作規則之外,必須遵守相關法規,避免以身觸法。

重點概念

營業秘密法

第 13-1 條、第 13-2 條

意圖為自己或第三人不法之利益,或損害營業秘密所有人之利益,處五年以下有期徒刑或拘役,得併科新臺幣一百萬元以上一千萬元以下罰金。前項之未遂犯罰之。

意圖在外國、大陸地區、香港或澳門使用,而犯前條第一項各款之罪者,處一年以上十年以下有期徒刑,得併科新臺幣三百萬元以上五千萬元以下之罰金

刑法

第 317 條 

妨害秘密罪,依法令或契約有守因業務知悉或持有工商秘密之義務,而無故洩漏之者,處一年以下有期徒刑、拘役或一千元以下罰金

第 358 條

妨害電腦使用罪,無故輸入他人帳號密碼、破解使用電腦之保護措施或利用電腦系統之漏洞,而入侵他人之電腦或其相關設備者,處三年以下有期徒刑、拘役或科或併科十萬元以下罰金

個資法

第 28 條、第 29 條

非公務機關違反本法規定,致個人資料遭不法蒐集、處理、利用或其他侵害當事人權利者,負損害賠償責任

如被害人不易或不能證明其實際損害額時,得請求法院依侵害情節,以每人每一事件新臺幣五百元以上二萬元以下計算

對於同一原因事實造成多數當事人權利受侵害之事件,經當事人請求損害賠償者,其合計最高總額以新臺幣二億元為限。

第 41 條、第 42 條

違反個資法規定,足生損害於他人者,處二年以下有期徒刑、拘役或科或併科新臺幣二十萬元以下罰金

意圖營利犯前項之罪者,處五年以下有期徒刑得併科新臺幣一百萬元以下罰金

意圖為自己或第三人不法之利益或損害他人之利益,而對於個人資料檔案為非法變更、刪除或以其他非法方法,致妨害個人資料檔案之正確而足生損害於他人者,處五年以下有期徒刑、拘役或科或
併科新臺幣一百萬元以下罰金

第 47 條、第 50 條

非公務機關有違反個資法規定者,由中央目的事業主管機關或直轄市、縣(市)政府處新臺幣五萬元以上五十萬元以下罰鍰,並令限期改正,屆期未改正者,按次處罰之。

非公務機關之代表人、管理人或其他有代表權人因該非公務機關依前三條規定受罰鍰處罰時,除能證明已盡防止義務者外,應並受同一額度罰鍰之處罰

銀行法

第 48 條

銀行非依法院之裁判或其他法律之規定,不得接受第三人有關停止給付存款或匯款、扣留擔保物或保管物或其他類似之請求。

銀行對於客戶之存款、放款或匯款等有關資料,除有下列情形之一者外,應保守秘密:

  1. 法律另有規定。
  2. 對同一客戶逾期債權已轉銷呆帳者,累計轉銷呆帳金額超過新臺幣五千萬元,或貸放後半年內發生逾期累計轉銷呆帳金額達新臺幣三千萬元以上,其轉銷呆帳資料。
  3. 依第 125 條之 2、第 125 條之 3 或第 127 條之 1 規定,經檢察官提起公訴之案件,與其有關之逾期放款或催收款資料。
  4. 其他經主管機關規定之情形。

此外根據銀行法第 133 條,第一百二十九條、第一百二十九條之一、第一百三十條、第一百三十一條第二款至第八款及第一百三十二條所定罰鍰之受罰人為銀行或其分行。銀行或其分行經依前項受罰後,對應負責之人應予求償。銀行或其分行經依前項受罰後,對應負責之人應予求償,因此在銀行工作對於資料的處理必須非常謹慎處理。

結論

因此在業界進行資料處理工作的我們更需要重視資料庫的資訊安全管理,最常見的做法即是針對不同資料表進行權限設定,更進一步針對機敏資訊的欄位 (例如: 客戶編號、卡片編號、…) 進行加密處理,並且以轉換處理過後的視圖提供給授權的使用者進行存取,最重要若因為業務需要相關機敏資訊,則必須要有主管覆核和稽核記錄的機制才能夠符合相關法令規範。

相關資源

軟體開發 Web Service Security (1)

基本介紹

教學目標

雲端運算與 Web Service 是有關聯性,一般來說,新技術的專有名詞,背後一定有歷史的演進,IT 技術是根據商業環境所做的改變,因此當學習新技術時,要同時學習技術的來源,如何使用技術以及技術未來的趨勢發展。

重點概念

企業應用

在使用 Web Service 之前,皆是透過中介軟體使得企業系統之間很順利的傳遞資料,例如: RMI 和 CORBA ,但系統之間是如何傳遞資料的呢?更進一步的探討,伺服器 A 要如何將資料傳送給伺服器 B 呢?先想辦法建立連線,簡單來說可以伺服器 A 先遠端登入,將檔案傳送到遠端,儲存在共享資料夾,在分享給對方,但是要手動,且伺服器 B 是否能正常且安全的開啟就無從得知,所以是否能自動化。

要考量如何傳送大量資訊,伺服器 A 是否能確保資訊已經正確完整傳送給伺服器 B,所以 Web Service 主要是伺服器與伺服器進行傳送大量的資訊,搭配時間的配置,達到全自動的
資訊傳送。

一般來說接生意訂單的流程,在大公司會經過許多的伺服器,而要如何透過中介軟體讓伺服器間彼此能正常溝通,或者透過 Web Service 為企業進行改進,使得 IT 人員藉由在配合商業模式改變,為企業產生更高的收益,讓 IT 人員產生更高的價值,除了技術之外還需考量 Global Localization,更進一步了解當地文化、避免完全橫向移植,以及保留被併購企業的核心價值。

當商業行為改變時,會有新的商業模式和環境,當流程系統的管理是 Web-based 則要使用 Web Service ,也就是 Workflow Management Applications,此外當需要減少溝通的成本,增加利潤,事先得知資訊和警訊,則必需要與內部的系統或上下流廠商要進行整合,也就是 Involve multi-domains (公司部門和相關公司),要如何在國際間上中下流相關廠商更有效的提供更詳細的資訊進行溝通,則必須使用 Web Service ,當有商業環境的需求,則 Web Service 將可以達到彈性的符合下一代商業環境的需求,帶來更多的效益。

此外對於 IT 專業人員而言,互通性就和安全性和可靠性一樣重要。這是由於技術異質性的增加,導致其 IT 基礎結構的內部和邊緣有更大的複雜性。當組織試圖將處理程序效能最佳化時,就帶來更大的資料和資訊整合上的需求。異質性也導致必須確保其解決方案可以成功 地運作於混合的 IT 環境中的資訊技術廠商更大的需求。為了滿足這些需求,解決互通性,以便更完善地連接人員、資料和不同的系統。

設計實作

但一般在設計實作 Web Service 時,皆會假設的環境是有一台伺服器,所有與伺服器與其有連線的電腦,就是公司的電腦,能存取伺服器的使用者,就是公司的使用者,但真的安全嗎?當與不確定來源伺服器的存取,則 Security Model 就必須做改變,或者當應因全球化的商業模式,則內部伺服器必須將資料傳送給外部伺服器,就必須考量資訊安全策略的問題,而要設計實作符合資訊安全的 Web Service ,最基本要確保三個特性。

  1. 機密性 (Confidentiality) ,基本應用就是加密 (Crypto)。
  2. 完整性 (Integrity) ,基本應用就是雜湊 (Hash)。
  3. 可用性 (Availability) ,基本應用就是避免被攻擊 (DoS)。

可用性在軟體工程中,則是談能提供服務的時間,在可信賴系統中,主要談容錯的問題。

接著 Web Service 不是做網站,不是有人在半自動的使用,而是伺服器進行全自動化的使用,但若是從應用程式的角度來看,就必須考慮識別確認 (Identification)、驗證檢查 (Authentication),以及授權權限 (Authorization),最後在使用 Web Service 必須先確認 Service Provider,接著再檢查提供的資訊是否正確,並且確認安全目標。

  1. 要提供訊息完整和機密的安全機制 (Mechanisms)。
  2. 確保服務的結果,要符合相關協定政策 (Policies)。
  3. 當資訊被搜尋時,必須是正確且被授權的 (Service Discovery)。

相關議題

此外研究安全議題,個人和伺服器的隱私,是最近幾年的趨勢,是一體兩面,當要提供 Web Service 則必需確認身份,但當伺服器儲存夠多的資訊,則會侵犯隱私,因此這不僅是技術能解決的問題,還需從管理政策方面去考量。主要透過加解密保護隱私,有機制可讓使用者進行同意,此外每個人的隱私標準不一致,最後當使用隱私相關資訊時,事後若有需求,則要強制刪除相關記錄。

最後再根據 OWASP 的 Web Service Security Cheat Sheet 在開發安全 Web Service 進行確認。

相關資源

2014Q1 工作心得 (2)

我們主要是透過 REST API 的方式,因此在上線之後可能會面臨資訊安全的問題,根據 REST Security Cheat Sheet 的分類主要可以分成五大類分別為驗證身份、授權使用、輸入驗證、輸出編碼和加密處理,因為我們主要是內容為主的 App,因此當我們會請編輯花費許多的時間確保內容品質,提供最高品質的資訊給使用者。

當編輯整理之後的資料非常有價值時,就會發生獨立開發者直接使用我們 API 進行同類型影音 App 的開發成為競爭者,直接對於我們造成直接的影響,我們為了解決此問題主要透過 nginx 的存取記錄,透過指令 cat [nginx log file] | cut -d’ ‘ -f1 | sort | uniq -c | sort -n 追蹤異常大量存取 API 的 IP 位址,嘗試透過 IP 和 User-agent 進行阻擋。

但是發現問題一樣存在,因此我們最後只好在犧牲不打算更新版本的 App 者進行 AES 256 bits 的加密處理,主要是將 Node.js 產生有價值的資訊透過 AES 256 bits 的加密之後再以 API 的方式回傳給 iOS 和 Android 的 App 進行有價值的資訊解密,呈現最完整的內容給使用者。