㈠ windows操作系統的訪問控制策略基於何種策略
自主訪問控制。
自主訪問控制指對某個客體具有擁有權（或控制權）的主體能夠將對該客體的一種訪問權或多種訪問權自主地授予其它主體，並在隨後的任何時刻將這些許可權回收。
這種控制是自主的，也就是指具有授予某種訪問權力的主體（用戶）能夠自己決定是否將訪問控制許可權的某個子集授予其他的主體或從其他主體那裡收回他所授予的訪問許可權。自主訪問控制中，用戶可以針對被保護對象制定自己的保護策略。
(1)最新的訪問控制模型擴展閱讀
訪問控制的實現機制建立訪問控制模型和實現訪問控制都是抽象和復雜的行為，實現訪問的控制不僅要保證授權用戶使用的許可權與其所擁有的許可權對應，制止非授權用戶的非授權行為；還要保證敏感信息的交叉感染。
以文件的訪問控制為例對訪問控制的實現做具體說明。通常用戶訪問信息資源（文件或是資料庫），可能的行為有讀、寫和管理。用Read或是R表示讀操作，Write或是W表示寫操作，Own或是O表示管理操作。
之所以將管理操作從讀寫中分離出來，是因為管理員也許會對控制規則本身或是文件的屬性等做修改，也就是修改我們在下面提到的訪問控製表。
㈡ 國內重要的 Go 語言項目：TiDB 3.0 GA，穩定性和性能大幅提升
TiDB 是 PingCAP 自主研發的開源分布式關系型資料庫，具備商業級資料庫的數據可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協議及生態，創新性實現 OLTP 及 OLAP 融合。
TiDB 3.0 版本顯著提升了大規模集群的穩定性，集群支持 150+ 存儲節點，300+TB 存儲容量長期穩定運行。易用性方面引入大量降低用戶運維成本的優化，包括引入 Information_Schema 中的多個實用系統視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因實現 View 可以執行，至此 TPC-H 22 個 Query 均可正常運行。新功能方面增加了窗口函數、視圖（實驗特性）、分區表、插件系統、悲觀鎖（實驗特性）。
截止本文發稿時 TiDB 已在 500+ 用戶的生產環境中長期穩定運行，涵蓋金融、保險、製造，互聯網， 游戲 等領域，涉及交易、數據中台、 歷史 庫等多個業務場景。不同業務場景對關系型資料庫的訴求可用 「百花齊放」來形容，但對關系資料庫最根本的訴求未發生任何變化，如數據可靠性，系統穩定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什麼樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規模集群的穩定性，支持單集群 150+ 存儲節點，300+TB 存儲容量長期穩定運行，主要的優化點如下：
1. 優化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調整心跳頻率，減小冷數據對集群的負擔。
2. 熱點調度策略支持更多參數配置，採用更高優先順序，並提升熱點調度的准確性。
3. 優化 PD 調度流程，提供調度限流機制，提升系統穩定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統穩定性。
眾所周知，資料庫查詢計劃的穩定性對業務至關重要，TiDB 3.0 版本採用多種優化手段提升查詢計劃的穩定性，如下：
1. 新增 Fast Analyze 功能，提升收集統計信息的速度，降低集群資源的消耗及對業務的影響。
2. 新增 Incremental Analyze 功能，提升收集單調遞增的索引統計信息的速度，降低集群資源的消耗及對業務的影響。
3. 在 CM-Sketch 中新增 TopN 的統計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的准確性，提升查詢計劃的穩定性。
4. 引入 Skyline Pruning 框架，利用規則防止查詢計劃過度依賴統計信息，緩解因統計信息滯後導致選擇的查詢計劃不是最優的情況，提升查詢計劃的穩定性。
5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優化點如下：
1. TiDB 持續優化 SQL 執行器，包括：優化 NOT EXISTS 子查詢轉化為 Anti Semi Join，優化多表 Join 時 Join 順序選擇等。
2. 優化 Index Join 邏輯，擴大 Index Join 運算元的適用場景並提升代價估算的准確性。
3. TiKV 批量接收和發送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。
4. TiKV 優化內存管理，減少 Iterator Key Bound Option 的內存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁碟 IO 的佔用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節點內可擴展性，進而提升單節點內並發處理能力和資源利用率，降低延時，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優化點，如下：
1. 提升 SQL 轉化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導入性能，單表支持批量導入。
3. 提升 TiKV-Importer 導入數據性能，支持將數據和索引分別導入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基於角色的許可權訪問控制） 是商業系統中最常見的許可權管理技術之一，通過 RBAC 思想可以構建最簡單「用戶-角色-許可權」的訪問許可權控制模型。RBAC 中用戶與角色關聯，許可權與角色關聯，角色與許可權之間一般是多對多的關系，用戶通過成為什麼樣的角色獲取該角色所擁有的許可權，達到簡化許可權管理的目的，通過此版本的迭代 RBAC 功能開發完成。
IP 白名單功能（企業版特性） ：TiDB 提供基於 IP 白名單實現網路安全訪問控制，用戶可根據實際情況配置相關的訪問策略。
Audit log 功能（企業版特性） ：Audit log 記錄用戶對資料庫所執行的操作，通過記錄 Audit log 用戶可以對資料庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數據執行情況。
加密存儲（企業版特性） ：TiDB 利用 RocksDB 自身加密功能，實現加密存儲的功能，保證所有寫入到磁碟的數據都經過加密，降低數據泄露的風險。
完善許可權語句的許可權檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句許可權檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢日誌內容，如：Coprocessor 任務數，平均/最長/90% 執行/等待時間，執行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產品易用性。
2. 新增系統配置項合法性檢查，優化系統監控項等，提升產品易用性。
3. 新增對 TableReader、IndexReader 和 IndexLookupReader 運算元內存使用情況統計信息，提高 Query 內存使用統計的准確性，提升處理內存消耗較大語句的效率。
4. 制定日誌規范，重構日誌系統，統一日誌格式，方便用戶理解日誌內容，有助於通過工具對日誌進行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調優的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接資料庫。
8. 新增快速恢復被刪除表功能，當誤刪除數據時可通過此功能快速恢復數據。
TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統，與行存儲系統實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協議從 TiKV 中實時同步行存數據並轉化成列存儲格式持久化到一組獨立的節點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統（TiKV）實時鏡像，實時鏡像可獨立於行存儲系統，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。
TiFlash 目前處於 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。
未來我們會繼續投入到系統穩定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。
穩定性方面 V4.0 版本將繼續完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布資料庫備份恢復難題；優化 PD 調度功能等。
性能方面 V4.0 版本將繼續優化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統調用，外部系統可根據元信息及負載情況動態伸縮集群規模，達成節省成本的目標。
我們相信戰勝「未知」最好的武器就是社區的力量，基礎軟體需要堅定地走開源路線。截止發稿我們已經完成 41 篇源碼閱讀文章。TiDB 開源社區總計 265 位 Contributor，6 位 Committer，在這里我們對社區貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區能夠有所收獲。
TiDB 3.0 GA Release Notes： https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/
㈢ 熟悉這四種許可權管理模型，產品迭代才能心裡有數
從本質來說，無論何種類型的許可權管理模型都可以抽象出三個基本的要素——即：用戶（user）、系統/應用（system/application）、策略（policy）。
策略決定了用戶和不同功能應用之間如何交互。反過來，也就是說，無論設計何種許可權管理的模型，都是基於這三個基本要素來展開。
本文聚焦於目前應用最廣的RBAC模型，但在這里提出三個基本要素，主要是為了幫助大家更好的理解許可權管理，不至於在眾多許可權模型中迷失。
不同的公司或軟體提供商，設計了無數種控制用戶訪問功能或資源的方法。但無論哪種設計，都可歸到四種經典許可權模型里——自主訪問控制(DAC，Discretionary Access Control)、強制訪問控制 (MAC，Mandatory Access Control)、基於角色訪問控制 (RBAC，Role-based Access Control) 和基於屬性訪問控制 (ABAC，Attribute-based Access Control).
（我覺得翻譯不好，但也找不到更貼切的。本文下面內容均以英文首字母來代替：DAC，MAC，RBAC，ABAC）。
本文主要就RBAC展開分析該模型的使用場景，以及如何基於該模型設計出合適的許可權管理體系。但從文章便於理解的完整性的角度來考慮，會對DAC，MAC和ABAC進行簡要的介紹。
DAC： 被操作對象，根據訪問控制規則，來判斷操作主體可對操作對象做哪些操作，比如只讀或者是可寫的許可權。而自主的含義，則是擁有某種許可權的用戶，可以把許可權賦予其他用戶。
MAC： 被操作對象及用戶兩方均有各自的許可權標識，用戶能否對對象進行操作，取決於許可權標識的對照關系。這種模型多用於等級制度明顯，信息訪問安全性要求高的場景，比如軍事。
ABAC和RBAC有很多相通的地方，而且相比較而言ABAC實際上更靈活，符合未來發展的方向。因此，我們分析完RBAC後，再回過頭來看ABAC。
Role-based Access Control，基於角色的許可權控制模型。
顧名思義，給用戶定義角色，通過角色來控制許可權。 目前來說基於角色許可權控制模型是應用較廣的一個。特別是2B方向SAAS領域，應用尤其常見。
如上圖示，用戶擁有角色，且可擁有多個角色，而每個角色對應不同許可權。
這樣的好處是：不必為每一個用戶去配置許可權，擁有極大的靈活性和便利性。而當用戶及許可權的量級又大到另一個級別時，又引入了角色組和許可權組概念，此處不做延伸，有興趣的讀者可以去搜些資料來看。
我們已經知道什麼是RBAC模型了，在分析怎麼來根據此模型來設計許可權體系之前，我們再把這個模型要素進行拆分一下。
首先是：用戶、角色、許可權。
而許可權，具體到某個軟體來說，實際上包含兩個方面。一個是菜單許可權，另一個是數據許可權。
不同的行業會有不同的使用場景，用戶角色許可權模型也會有不同程度上的變化。但歸到底層來說，還是離不開上面我畫的這個圖。
上面這個圖是從官網看到的，銷售自動化領域十分典型的用戶許可權管理設計。
接下來，我們來抽象一個場景或者說案例，來輔助我們理解整個許可權管理設計的過程。假設A公司是個中大型的生產製造公司，公司有OA、HR、CRM、ERP一系列管理軟體。公司員工以萬計，不同人員職責不同，體現在管理軟體上，就是會需要使用不同的功能來完成工作。
帳號是人和軟體進行交互時的一個身份的轉化。賬號的背後，代表了這個操作的人。賬號管理應該是所有需要和系統交互的人的統一管理，包含基礎信息，比如：這個人的名字，性別、手機號、部門以及其他屬性。
角色管理，就是要從實際場景出發，比如：使用系統的企業或者團體，有哪幾類使用的角色——也就是說，有哪幾類人，是需要有不同的業務菜單和業務數據的。
說到底，角色管理，就是把這個角色對應的人平時工作需要的菜單、功能給劃到一個組里。給這一個個的操作組定義不同的名稱——即角色名稱。
當然，這個角色管理除了規定了該角色的人平時可對哪些功能進行查看操作，還需規定這個角色，能看到哪些范圍內的數據。也就是前面提到的，許可權實際上包含的是菜單許可權和數據許可權兩部分。
系統內功能控制的顆粒度越細，對使用者來說配置角色便越靈活，但對系統的設計者來說，系統的復雜度自然也會上升，成本也會增加。
因此，到底控制到哪一層級，就要視具體業務場景來定，比如：有些行業的系統，可能控制到一級菜單就可以（某些SAAS工具），但有些系統，不僅需要控制所有的子級菜單，每一個按鈕操作，甚至還會需要控制到不同的欄位（比如Salesforce的許可權控制系統）。
不過，我們抽象出了基本的模型，根據實際業務再去發散，就不是最困難的事了。
至此，我們可以了解到：RBAC模型實際上能解決大部分的許可權設計問題了。
那麼，ABAC到底是什麼呢？它存在的意義在哪裡？關於未來的許可權設計趨勢，它能帶給我們什麼啟發呢？
帶著這些問題，我們先來看看到底什麼是ABAC模型。
ABAC，Attribute-based Access Control. 基於屬性的訪問控制。而屬性，總的來說有三類：用戶屬性、系統或應用被訪問屬性（數據和操作）、環境屬性。
也就是說，系統根據一組或多組屬性是否滿足預設規則來動態的控制，誰可以訪問哪些功能數據和操作。RBAC模型，其實可以看成是靜態的、單組屬性的ABAC模型。
用例子來理解這個模型就是：只有當用戶角色為Admin，在工作時間內，且處在C棟大樓B實驗室，才可以訪問D文件。
實際上，ABAC是個可以以最細顆粒度來管理許可權的模型。它可以讓設計者，利用任何一個用戶屬性、環境屬性，或者多個屬性之間的交集、並集等來組合出動態的許可權判斷邏輯。
它是這么強大，既可以有效的幫助信息辨別能力差的用戶過濾垃圾信息。也可以讓商家用到營銷廣告填滿你生活的每個角落卻不自知。
但我一直堅信， 科技 絕對是讓生活更美好。
許可權管理，可能是每個2B產品經理需要面對的問題。但無論C端還是B端的產品，了解許可權管理的設計法則，讓自己更好的理解產品的架構，讓產品的每次迭代都心裡有數。
題圖來自Unspalsh, 基於CC0協議。