這些最佳做法反映了由多個職能團隊的資深 Looker 分享的建議。這些洞察資料是我們與 Looker 客戶合作多年，從導入到長期成功的經驗所得。這些做法適用於大多數使用者和情況，但在實作時，請務必根據實際情況做出最佳判斷。
本頁面提供 Looker 執行個體管理員設定內容存取權控管的示範範例。我們將逐步介紹實作程序，從新專案開始，接著介紹模型、模型集、權限集、群組、角色和使用者屬性。
首先，請透過以下比喻瞭解這個情境中的主要 Looker 功能：
專案就像是家。模型是指住家中充滿特定內容的房間。
模型集是一組房間或單一房間 (臥室、廚房)。
權限集是活動檢查清單，可指定使用者可在房間內執行的動作 (進食、玩耍、睡覺)。
群組是將具有共同特徵 (成人、兒童、訪客) 的使用者編組在一起的一種方式。
角色是指如何為不同群組的使用者提供活動檢查清單。
使用者屬性是開啟房屋內特殊物品 (水壺、電動工具) 的鑰匙。
情境
以下是新創公司中包含財務、銷售和產品團隊的範例。我們的執行長是唯一的管理員，她希望每個團隊只看見與自己相關的內容，但各團隊的副總裁應能存取所有團隊的內容。她希望為一般員工、主管和副總裁提供不同的功能存取權。
- 一般員工應可查看及探索自己模型中的資料。
- 管理員應具備標準存取權，並能下載及排程內容。
- 副總裁應具備幾乎所有權限，除了少數留給執行長的權限。
執行長希望業務人員能夠查看自己的活動資料，但無法查看其他業務人員的個別銷售數字。不過，銷售經理應可查看每位業務員的數字。最後，有些財務欄位含有機密資訊，她希望為使用該模型的一般員工遮蓋這些資訊。
以下是組織圖：
下圖顯示這個新創公司範例的組織架構：
- 執行長
- 財務部門副總裁
- 財務經理
- 會計師
- 銷售副總裁
- 西區銷售經理
- 西區銷售專員
- 東區銷售經理
- 東區銷售專員
- 產品副總裁
- 產品經理
- 工程師
實作所需的存取控制項時，請按照下列步驟操作：
- 建立專案：專案是資料庫連線和資料模型之間的結構連結。
- 新增模型：決定要向哪些使用者顯示哪些資料。
- 建立模型集：將相關模型分組。
- 建立權限集：明確定義使用者可在模型集中執行的動作。
- 建立群組：將相似使用者歸入同一群組。
- 建立角色：建立模型集、權限集和群組之間的連結。
- 編輯內容存取權：管理使用者可透過資料夾查看哪些資訊主頁和 Look。
- 新增資料篩選器：進一步篩選特定使用者可在模型中存取的資料。
1. 建立專案
首先，我們需要一個專案，這是一或多個模型的容器。如果您已設定專案，可以略過這個步驟。如要前往「LookML 專案」頁面，請在 Looker 的「開發」部分選取「專案」，然後選取「新 LookML 專案」建立新專案。如需建立新專案的詳細操作說明，請參閱「產生模型」說明文件頁面。
在「New Project」頁面上，我們會使用下列設定建立專案：
- 在「Name」部分，我們為專案命名。
- 在「Starting Point」部分，我們選取「Generate Model from Database Schema」。
- 在「Connection」下拉式選單中，選取資料庫連線的名稱。
- 在「Build Views From」部分，我們會選取「All Tables」選項，讓 LookML 產生器為資料庫中的每個資料表建立檢視表檔案。
設定新專案的所需設定後，我們選取「Create Project」。
建立專案後，您會看到系統自動產生的 LookML 模型。此時，您必須使用「Configure Git」按鈕，為專案設定版本管控。如需設定版本控制的詳細操作說明，請參閱「設定及測試 Git 連線」說明文件頁面。
2. 新增模型
資料模型就像是可自訂的資料庫入口網站。每個模型向使用者揭露的資料可能不同。在本例中，業務人員需要的資料與工程師不同，因此我們會新增個別模型，向各類使用者顯示資料庫中的適當資訊。
在 LookML 專案中，我們會新增 LookML 模型檔案，並為每個所需模型 (finance、sales 和 product) 命名。請務必在每個模型檔案中定義至少一個 Explore，這樣我們才能在建立模型集時選取模型 (否則，模型不會顯示在選項中)。如要進一步瞭解如何在模型檔案中使用 explore 參數，請參閱「瞭解模型和檢視檔案」說明文件頁面。
成功新增模型後，我們仍需要設定模型。如要 設定模型，請返回「開發」部分的「專案」頁面，現在應該會在每個模型名稱旁邊顯示紅色文字「Configuration required for use」(使用前需設定)。
選取每個模型旁的「設定」，我們會確認專案名稱和允許模型使用的連線是否正確，然後儲存。
所有模型都設定正確後，先前遇到的紅色設定問題訊息就不會再顯示。
請注意，在 Looker 中，如果您向使用者授予某個模型的 see_lookml 或 develop 權限，就會授予該使用者該專案中所有模型的權限。因此，如果您想區隔 LookML 的查看或開發權限，請建立個別專案。否則，您應該建立新模型。模型權限足以確保只有特定人員可以查詢特定資料。
如要進一步瞭解權限，請參閱有關角色的說明文件。
3. 建立模型集
各部門的資料模型都已設定完成，現在我們會將各部門的對應模型加入建構的模型集中。如要建立新的模型集合，請前往「管理」面板中的「角色」頁面，然後選取「新增模型集合」。如需建立新模型集的詳細操作說明，請參閱「角色」說明文件頁面。
建立新模型集後，這些模型集會顯示在「Roles」頁面的「Model Sets」部分，如以下範例螢幕截圖所示：
4. 建立權限集
接下來，我們將使用剛建立的模型集來建立權限集。如同我們在設定情境時所述，我們希望四個層級的權限對應到組織架構圖中的四個階層，且較高層級應包含較低層級的權限。在本情境中，我們會將權限集識別為下列項目：
- 執行長具備管理員權限組合。
- 副總裁具備「有限管理員」權限集。
- 管理員擁有「下載和分享」權限集。
- 一般員工擁有「查看和探索」權限組合。
如要建立新的權限集，請前往「管理」面板中的「角色」頁面，然後選取「新增權限集」。我們會為每個權限層級選取適當的權限。一般來說，權限組合應盡量避免重疊，每個組合只應加入使用者需要的特定權限。這是因為我們會為部分使用者提供多個權限組合，因此想瞭解每個權限組合允許的內容。不過，由於樹狀結構的關係，通常需要一些重疊。
在本例中，我們希望「查看和探索」權限組合可讓使用者查看內容、提出問題，以及儲存實用的資訊方塊。因此，我們會授予他們與查看內容相關的權限 (例如 see_looks 和 see_user_dashboards)、explore 權限和 save_content 權限。值得注意的是，see_lookml 只供開發人員使用，而 see_sql 則只供瞭解 SQL 且可信任的使用者查看資料庫結構。所有這些權限都嚴格位於 access_data 分支中。我們不會在樹狀結構底部提供任何 see 權限，因為這些是管理權限。
針對「下載和分享」權限組合，我們會新增下載、排程、分享、建立公開 Look (可讓使用者與非 Looker 使用者分享 Look) 和 see_schedules 的相關權限 (因為他們可以建立排程，因此也能透過「管理」面板查看排程)。
在設定「查看和探索」和「下載和分享」權限集時，選取的欄位只有父項權限，用於選取 access_data 分支中新增的子項權限。因此，由於擁有「下載及分享」權限組的使用者也會擁有「檢視及探索」權限組，因此無須在「下載及分享」權限組中加入 see_lookml_dashboards、see_user_dashboards 和 explore 等權限，因為這些權限不包含「下載及分享」權限組所需的任何子權限。
最後，我們會在「限制管理員」權限組合中，新增樹狀結構底部的大部分管理權限，但不包括 CEO 只想保留給自己的 manage_models 和 sudo 權限。如下所示：
完成後，權限集將包含下列權限：
- 管理員：管理員權限組合是為範例公司的執行長保留，包含所有權限。
- 受限管理員：受限管理員權限組合包含
create_prefetches、login_special_email、manage_homepage、manage_spaces、see_alerts、see_datagroups、see_logs、see_pdts、see_queries、see_users和update_datagroups權限。 - 下載和分享：下載和分享權限組合包含
access_data、create_public_looks、download_with_limit、download_without_limit、save_content、schedule_external_look_emails、schedule_look_emails、see_looks、see_schedules、send_outgoing_webhook、send_to_s3和send_to_sftp權限。 - 「查看和探索」：「查看和探索」權限組合包含
access_data、create_table_calculations、explore、save_content、see_drill_overlay、see_lookml_dashboards、see_looks和see_user_dashboards權限。
如要查看屬於現有權限集的權限，請前往「角色」管理員頁面，然後前往「權限集」部分。
5. 建立群組
接下來，我們要建立群組並將使用者分組。我們會為每個部門的標準員工和主管建立群組，因為這些群組最終會與我們稍後建立的不同角色相符。副總裁會在自己的群組中，而執行長則不需要群組。完成後，「群組」頁面應會列出下列群組及其對應的群組 ID (由 Looker 自動產生)。例如：
| ID | 名稱 |
|---|---|
| 1 | 所有使用者 |
| 3 | 金融 |
| 4 | 銷售 |
| 5 | 產品 |
| 7 | 銷售經理 |
| 8 | 產品經理 |
| 9 | 財務管理員 |
| 10 | 副總裁 |
群組建立完成後，我們需要將使用者加入這些群組。如需將使用者加入群組的操作說明，請參閱「群組」說明頁面。
將使用者新增至我們建立的群組時，請注意，由於我們採用的權限結構，較高層級的群組可能會納入較低層級的群組。舉例來說，我們希望副總裁位於「財務」群組中，但銷售經理則不位於「產品」群組中。解決這個問題的有效方法，就是先將使用者新增至較高層級群組 (例如副總裁)，這樣我們就能將他們新增為較低層級群組的成員。
6. 建立角色
我們現在已建立模型集、權限集和群組，可以使用角色將這些項目組合在一起。每個角色都會有一組權限和一組模型，並可能包含一或多個群組。由於角色必須包含模型集，我們會再次為各部門的標準員工和管理員建立角色。
- 標準角色：標準角色會包含「查看和探索」權限組合，以及對應的模型組合。將標準角色指派給該部門的標準和管理員群組，以及副總裁。舉例來說，您可以將「標準財務」角色指派給「財務」和「財務經理」群組，以及財務副總裁。
- 管理員角色：管理員角色會擁有「下載和分享」權限組合，以及對應的模型組合。這些角色應指派給對應部門的管理員群組，以及該部門的副總裁。
- 管理員角色：管理員角色會擁有「下載和分享」權限組合，以及對應的模型組合。這些角色應指派給對應部門的管理員群組，以及該部門的副總裁。
- 副總裁角色：副總裁角色會具備「有限管理員」權限組合和「全部」模型組合。這個角色會指派給 VP 群組。
7. 編輯內容存取權
下一步是整理資料夾存取權限，讓每個群組都能存取自己的內容 (且只能存取自己的內容)。以下是示例執行個體中的資料夾版面配置，您可以前往管理面板中的「內容存取」頁面查看：
資料夾的存取權遵循階層繼承規則。如要進一步瞭解這項功能的運作方式，請參閱有關存取層級和存取權控管和權限管理的說明文件。
根據資料夾存取權規則，我們想將「Shared」資料夾的「View」存取權授予所有使用者。我們會為每個群組提供「檢視」存取權，讓他們可以存取樹狀結構中位於群組存取權限範圍內的上層資料夾。這樣一來，當我們沿著樹狀結構往下檢查時，如果不希望某個群組看到某個資料夾，我們就不會在授予存取權時納入該群組。
我們可以將「管理存取權、編輯」存取權層級授予資料夾中的群組，藉此控管哪些人可以查看該資料夾。在本例中，我們只希望讓執行長和副總裁擁有這些權限；其他使用者只能對所需的資料夾擁有「檢視」權限。
8. 使用使用者屬性新增資料存取權限制
本節說明如何防止特定使用者存取其可存取模型的特定資料列或資料欄。請注意，我們的執行長希望業務人員能夠查看自己的活動資料，但不包括他人的活動資料。不過，銷售經理應可查看每位業務員的數字。為此，我們會利用使用者屬性和 sql_always_where 參數。
建立使用者屬性
首先，我們會建立名為 access_level 的新使用者屬性，並隱藏使用者。這樣一來，我們就能為不同的群組定義存取層級。建立使用者屬性時，我們會設定下列值：
- Name (名稱)：
access_level - 標籤：存取層級
- 資料類型：字串
- 使用者存取權：編輯
- 隱藏值：否
在本例中，我們會取消勾選「Set a default value」方塊。
建立欄位時，我們會設定三個存取層級：基本、進階和完整。我們會將這些層級分別指派給標準、經理和副總裁群組。方法是在同一個部分的「Group Values」分頁中執行這項操作。詳情請參閱「使用者屬性」說明文件的「為使用者群組指派值」一節。
由於這些規則的順序很重要，我們會將最高的存取權值放在清單頂端，以便覆寫位於底部的較低存取權值。如要進一步瞭解這項行為，請參閱「使用者屬性」說明文件頁面。
使用使用者屬性篩選資料列
我們假設已經建立了包含所有銷售資訊的探索，我們會檢查查詢探索的使用者存取層級。如果存取層級為「基本」 (我們已將此層級授予所有標準業務人員)，我們一律會根據使用者名稱篩選探索，讓每位業務人員只能存取自己的資料列。如果存取層級為「Premium」或「Full」，系統就不會篩除查詢。根據預設，我們有一個名為「Name」的使用者屬性，這是 Looker 使用者的名稱。探索的 LookML 如下所示：
explore: sales_info {
sql_always_where: {% if {{_user_attributes['access_level']}} == "Basic" %}
${sales_info.name} = "{{_user_attributes['name']}}"
% endif %
;;
}
使用使用者屬性篩選資料欄資料
最後，財務模型中有一些 PII (個人識別資訊) 欄，我們也想隱藏這些欄，不讓部分使用者看到。為此，我們可以使用已建立的使用者屬性，以及「使用者屬性」說明頁面中，在 Looker 中套用資料庫層級權限的操作說明，讓只有具備完整存取層級的使用者，才能查看 PII 欄位。
大功告成！我們已完成設定內容和資料存取權控管機制，所有使用者都能免費探索 Looker。這樣一來，我們就能確保他們只會看到我們允許他們觀看的內容。