ตั้งค่า Snowflake MCP สำหรับ Notion

ในเอกสารช่วยเหลือนี้

ดูวิธีเชื่อมต่อ Snowflake กับเอเจนต์ที่กำหนดเองหรือ Notion Agent เพื่อถามเกี่ยวกับข้อมูลบริษัทได้ใน Notion

ข้ามไปยังคำถามที่พบบ่อย

ฟีเจอร์บางอย่างยังอยู่ในช่วงอัลฟ่า

ฟีเจอร์บางอย่างที่กล่าวถึงในบทความนี้ รวมถึงการเชื่อมต่อ MCP ที่กำหนดค่าในระดับพื้นที่ทำงานและการอนุญาตสิทธิ์รายผู้ใช้ในเอเจนต์ที่กำหนดเอง ขณะนี้ยังอยู่ในช่วงอัลฟ่าและอาจยังไม่พร้อมใช้งานในพื้นที่ทำงานของคุณ

หากต้องการขอสิทธิ์เข้าถึง โปรดติดต่อทีมดูแลลูกค้า Notion หรือ สมัครเข้าร่วมโปรแกรมการเข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูล →

เอเจนต์ที่กำหนดเอง และ Notion Agent ของคุณสามารถเชื่อมต่อกับ Snowflake ผ่านเซิร์ฟเวอร์ MCP (Model Context Protocol) ที่ Snowflake เรียกใช้งาน เมื่อตั้งค่าเรียบร้อยแล้ว คุณสามารถถามเอเจนต์ของคุณเกี่ยวกับข้อมูลในคลังข้อมูล Snowflake และรับคำตอบได้โดยตรงใน Notion

การตั้งค่าจะแบ่งเป็นขั้นตอน และมีผู้รับผิดชอบในแต่ละส่วนดังนี้:

  • ผู้ดูแลระบบ Snowflake ตั้งค่าบทบาท คลังประมวลผล และเซิร์ฟเวอร์ MCP ที่ Snowflake จัดการ

  • เจ้าของหรือผู้ดูแลระบบพื้นที่ทำงาน Notion กำหนดค่าการเชื่อมต่อ Snowflake MCP สำหรับพื้นที่ทำงาน

  • สมาชิกในพื้นที่ทำงาน สามารถเชื่อมต่อกับ Snowflake MCP ผ่านเอเจนต์ที่กำหนดเองโดยใช้ข้อมูลประจำตัว Snowflake ของตนเอง หรือเชื่อมต่อ Snowflake เข้ากับ Notion Agent ของตนโดยตรง ขั้นตอนที่ 1–10 ของบทความนี้เหมือนกันสำหรับทั้งสองวิธี โดยจะแยกเป็นคนละวิธีตั้งแต่ขั้นตอนที่ 11 ตามเอเจนต์ที่คุณต้องการเชื่อมต่อ

  • เครื่องมือที่พร้อมใช้งานอาจแตกต่างกันไปตามภูมิภาคคลาวด์ Snowflake ของคุณ

  • เซิร์ฟเวอร์ MCP ที่มีการจัดการของ Snowflake ไม่พร้อมใช้งานในจีนแผ่นดินใหญ่หรือภูมิภาคของรัฐบาล

  • พื้นที่ทำงาน Notion ของคุณต้องใช้แพ็คเกจ Business หรือแพ็คเกจ Enterprise

  • ใช้ Notion บนเว็บหรือเดสก์ท็อป ฟีเจอร์นี้ไม่พร้อมใช้งานบนมือถือ

  • บริษัทของคุณต้องมีบัญชี Snowflake

  • ในการสร้าง เอเจนต์ที่กำหนดเอง คุณต้องได้รับอนุญาตให้สร้างเอเจนต์ในพื้นที่ทำงานของคุณ

การตั้งค่าที่แชร์ร่วมกันไม่ได้ให้ข้อมูลเดียวกันแก่ทุกคน

พื้นที่ทำงานจะจัดเก็บรายละเอียดการเชื่อมต่อ รวมถึงรหัสไคลเอนต์ OAuth และข้อมูลลับ รายละเอียดเหล่านี้ใช้กำหนดค่าการเชื่อมต่อ ไม่ใช่ข้อมูลสำหรับเข้าสู่ระบบที่ใช้ร่วมกัน แต่ละคนเข้าสู่ระบบ Snowflake ด้วยบัญชีของตนเอง ไม่ว่าจะใช้เอเจนต์ที่กำหนดเองหรือ Notion Agent ของตนเอง เอเจนต์ก็เข้าถึงได้เฉพาะข้อมูลที่บัญชีนั้นมีสิทธิ์เข้าถึงเท่านั้น

ก่อนที่ทีมของคุณจะเชื่อมต่อ Snowflake เข้ากับ Notion ผู้ดูแลระบบ Snowflake จำเป็นต้องตั้งค่าการเข้าถึง นี่เป็นขั้นตอนที่ซับซ้อนที่สุด และคุณต้องทำเพียงครั้งเดียวเท่านั้น โปรดทำงานร่วมกับผู้ดูแลระบบพื้นที่ทำงาน Notion ของคุณ: Notion จะให้ URI การเปลี่ยนเส้นทาง และ Snowflake จะให้ OAuth client ID และ secret แก่คุณ

ตั้งค่าบทบาทและคลังประมวลผล สร้างเซิร์ฟเวอร์ MCP ที่ Snowflake จัดการ ให้สิทธิ์เข้าถึงทรัพยากรที่จำเป็น กำหนดค่าขอบเขต OAuth และการผสานรวมด้านความปลอดภัย แล้วเพิ่มนโยบายเครือข่ายหากองค์กรกำหนด

รวบรวมค่าเหล่านี้ก่อน

กรอกข้อมูลในแผ่นงานนี้ร่วมกับผู้ดูแลระบบพื้นที่ทำงาน Notion ของคุณก่อนที่คุณจะเริ่มต้น สมาชิกสามารถข้ามขั้นตอนนี้และลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของตนเองได้เมื่อการตั้งค่าเสร็จสมบูรณ์

เก็บ OAuth client secret ไว้เป็นความลับ

ห้ามเพิ่มลงใน Slack, ทิกเก็ต, ระบบควบคุมเวอร์ชัน หรือประวัติเทอร์มินัล ให้แชร์ผ่านช่องทางที่ปลอดภัยและได้รับการอนุมัติเท่านั้น

ฟิลด์

ค่า

เจ้าของ

ตัวระบุบัญชี Snowflake

<organization-account>

ผู้ดูแลระบบ Snowflake

ฐานข้อมูล MCP

<database_name>

ผู้ดูแลระบบ Snowflake

สคีมา MCP

<schema_name>

ผู้ดูแลระบบ Snowflake

เซิร์ฟเวอร์ MCP

<mcp_server_name>

ผู้ดูแลระบบ Snowflake

คลังประมวลผล

<warehouse_name>

ผู้ดูแลระบบ Snowflake

บทบาทการเข้าถึง

<mcp_access_role>

ผู้ดูแลระบบ Snowflake

URL เซิร์ฟเวอร์

https://<account_host>/api/v2/databases/<database_name>/schemas/<schema_name>/mcp-servers/<mcp_server_name>

ผู้ดูแลระบบ Snowflake

ขอบเขตบทบาทหลัก

session:role:<mcp_access_role>

ผู้ดูแลระบบ Snowflake

URI การเปลี่ยนเส้นทาง

คัดลอก URI ที่ Notion สร้างขึ้น

ผู้ดูแลระบบพื้นที่ทำงาน Notion

ID ไคลเอ็นต์ OAuth

ดึงข้อมูลจาก Snowflake

ผู้ดูแลระบบ Snowflake

ข้อมูลลับของไคลเอ็นต์ OAuth

ส่งผ่านช่องทางที่ได้รับอนุมัติสำหรับส่งข้อมูลลับ

ผู้ดูแลระบบ Snowflake

ชื่อโฮสต์ของบัญชีใช้ยัติภังค์ ไม่ใช่ขีดล่าง ตรวจสอบให้แน่ใจว่าชื่อออบเจกต์แต่ละชื่อใน URL ของเซิร์ฟเวอร์ตรงกับชื่อออบเจกต์ที่เกี่ยวข้องใน Snowflake

ใช้บทบาทเฉพาะที่มีสิทธิ์เท่าที่จำเป็นและคลังประมวลผลที่ได้รับอนุมัติ 1 แห่งเมื่อทำได้

บทบาทที่จำกัดโดยไม่มีบทบาทรอง (แนะนำ) โมเดลนี้เข้าใจและตรวจสอบได้ง่ายกว่า ตั้งค่า OAUTH_USE_SECONDARY_ROLES = NONE ระบุ ALLOWED_ROLES_LIST และใช้ขอบเขต Notion session:role:<mcp_access_role>

บทบาทรองเริ่มต้นของผู้ใช้ (ไม่บังคับ) ใช้โมเดลนี้เฉพาะเมื่อเซิร์ฟเวอร์ต้องการสิทธิ์ที่สืบทอดมาจาก DEFAULT_SECONDARY_ROLES ของผู้ใช้ Snowflake แต่ละคน ตั้งค่า OAUTH_USE_SECONDARY_ROLES = IMPLICIT ละเว้น ALLOWED_ROLES_LIST และใช้ขอบเขตบทบาทหลักที่ระบุอย่างชัดเจน Snowflake ไม่อนุญาตให้ใช้บทบาทรอง IMPLICIT ร่วมกับ ALLOWED_ROLES_LIST ดังนั้นให้ละเว้นรายการที่อนุญาตเมื่อใช้โมเดลนี้

ขั้นตอนที่ 2: สร้างหรือเลือกบทบาทและคลังประมวลผล

ใช้บทบาทเฉพาะที่มีสิทธิ์น้อยที่สุดสำหรับเซิร์ฟเวอร์ MCP ทุกครั้งที่เป็นไปได้

ให้สิทธิ์บทบาทนี้ผ่านกระบวนการจัดการข้อมูลประจำตัวตามปกติของคุณ หาก Okta หรือ SCIM จัดการการเป็นสมาชิกบทบาทของ Snowflake อย่าเพิ่มผู้ใช้ด้วยตนเองนอกกระบวนการนั้น

สร้างหรือเลือกฐานข้อมูลและสคีมาที่เป็นเจ้าของโดยทีมที่จะเรียกใช้เซิร์ฟเวอร์

สำหรับคำถามทางธุรกิจที่มีการกำกับดูแล คุณสามารถเปิดเผย Cortex Agent เป็นเครื่องมือที่สมาชิกใช้ได้ ซึ่งจะเก็บมุมมองเชิงความหมาย คิวรีที่ตรวจสอบแล้ว การค้นหา และการประสานงานไว้ในที่เดียว Cortex Agent เป็นตัวเลือกเสริม หากคุณสร้างขึ้นมา ให้ใช้ข้อมูลจำเพาะด้านล่าง หากคุณแทนที่เอเจนต์ที่มีอยู่ ตรวจสอบให้แน่ใจว่าเอเจนต์ที่นำมาแทนที่ตรงกับข้อมูลจำเพาะที่คุณอนุมัติแล้ว

execution_environment ต้องอยู่ในโครงสร้างซ้อนภายใต้ทรัพยากรเครื่องมือ Analyst เท่านั้น

หากคุณใส่ warehouse ไว้ที่ระดับบนสุด ระบบอาจสร้างนิยามของเอเจนต์ได้ แต่เครื่องมือจะไม่มี warehouse สำหรับประมวลผลขณะทำงาน

ประเภทเครื่องมือ MCP ของ Snowflake อื่นๆ ที่รองรับ ได้แก่ CORTEX_ANALYST_MESSAGE, CORTEX_SEARCH_SERVICE_QUERY, GENERIC และ SYSTEM_EXECUTE_SQL

หากคุณต้องการเข้าถึง SQL โดยตรง ให้ตั้งค่าการเข้าถึงนั้นบนเซิร์ฟเวอร์ MCP แยกต่างหาก โดยใช้บทบาทเฉพาะที่ได้รับสิทธิ์เท่าที่จำเป็น และตรวจสอบให้แน่ใจว่าบทบาทนั้นมีสิทธิ์อ่านอย่างเดียว

การเพิ่ม SYSTEM_EXECUTE_SQL ลงในเซิร์ฟเวอร์ของเอเจนต์ที่มีการควบคุมอาจทำให้ไคลเอ็นต์ข้ามมุมมองเชิงความหมายและคิวรีที่ตรวจสอบแล้วได้

ตั้งชื่อและคำอธิบายที่ชัดเจนให้กับเครื่องมือแต่ละอย่าง อธิบายว่าครอบคลุมข้อมูลใด ผลลัพธ์มีรายละเอียดเพียงใด และควรใช้เมื่อใด สิ่งนี้จะช่วยให้เอเจนต์เลือกเครื่องมือที่เหมาะสมได้

สิทธิ์ USAGE สำหรับเซิร์ฟเวอร์ MCP ช่วยให้บทบาทเชื่อมต่อกับเซิร์ฟเวอร์และดูเครื่องมือที่มีได้ แต่ไม่ได้ให้สิทธิ์เข้าถึงคลังประมวลผล เอเจนต์ มุมมองเชิงความหมาย บริการค้นหา โพรซีเดอร์ที่จัดเก็บไว้ หรือข้อมูลเบื้องหลัง จึงต้องให้สิทธิ์บทบาทเข้าถึงทรัพยากรแต่ละรายการที่เครื่องมือของเซิร์ฟเวอร์ต้องใช้

ให้สิทธิ์เข้าถึงเฉพาะทรัพยากรเพิ่มเติมที่แต่ละเครื่องมือจำเป็นต้องใช้ เช่น ให้สิทธิ์ SELECT สำหรับมุมมองเชิงความหมายที่อนุมัติแล้ว ให้สิทธิ์ USAGE สำหรับบริการ Cortex Search หรือให้สิทธิ์ USAGE สำหรับฟังก์ชันหรือโพรซีเดอร์ที่ระบุ อย่ามอบบทบาทนี้ให้ PUBLIC หรือให้สิทธิ์แบบครอบคลุมกับออบเจกต์ปัจจุบันหรือในอนาคต

ก่อนตั้งค่า OAuth ให้ตรวจสอบเซิร์ฟเวอร์ MCP และสิทธิ์ที่มอบให้:

กำหนดค่าสคีมา MCP ให้แสดงบทบาทที่สมาชิกควรร้องขออย่างเจาะจง:

ใช้ขอบเขตบทบาทที่ชัดเจน ห้ามใช้ session:role:all Snowflake จะถือว่าค่านั้นเป็นบทบาทหลักเริ่มต้นของผู้ใช้ ไม่ใช่การเข้าถึงทุกบทบาท และนโยบายสำหรับบทบาทที่มีสิทธิ์พิเศษอาจบล็อกค่านั้นได้ บทบาทที่ชัดเจนจะทำให้การเข้าถึงที่ร้องขอมีความชัดเจนและตรวจสอบได้ง่ายขึ้น

ก่อนเรียกใช้ SQL นี้ ให้ประสานงานกับผู้ดูแลพื้นที่ทำงาน Notion ของคุณ ขอให้พวกเขาป้อน URL เซิร์ฟเวอร์ Snowflake ในแบบฟอร์มการตั้งค่า MCP ของพื้นที่ทำงาน และเปิดใช้งาน Manually configure authentication และ Use a workspace-shared OAuth client Notion จะสร้าง URI การเปลี่ยนเส้นทาง คัดลอก URI นั้นแล้วส่งให้ผู้ดูแลระบบ Snowflake หลังจาก Snowflake สร้างรหัสไคลเอ็นต์และรหัสลับแล้ว ผู้ดูแลพื้นที่ทำงานจะสามารถตั้งค่าการเชื่อมต่อให้เสร็จสมบูรณ์ได้

ใช้ URI การเปลี่ยนเส้นทางให้ตรงตามที่ Notion ให้มาทุกประการ อย่าเพิ่มเครื่องหมายทับท้าย URI หรือพารามิเตอร์คิวรี และอย่าเปลี่ยนโฮสต์

การตั้งค่า IS_AGENTIC = TRUE จะทำเครื่องหมายเซสชันที่สร้างผ่านการรวมระบบนี้ว่าเป็นเซสชันของเอเจนต์ จากนั้นฟังก์ชัน IS_AGENT_ACTIVATED() ของ Snowflake จะส่งคืนค่า TRUE ซึ่งช่วยให้ Snowflake สามารถใช้การตรวจสอบและการกำกับดูแลเฉพาะสำหรับเอเจนต์ได้ หากคุณใช้รูปแบบบทบาทรองที่เป็นทางเลือก ให้ตั้งค่า OAUTH_USE_SECONDARY_ROLES = IMPLICIT และละเว้น ALLOWED_ROLES_LIST ไว้

ระยะเวลาที่โทเค็นรีเฟรชใช้ได้ 7776000 วินาทีเท่ากับ 90 วัน ก่อนใช้งาน ให้ตรวจสอบว่าค่านี้สอดคล้องกับนโยบายการอนุญาตใหม่และการเปลี่ยนโทเค็นขององค์กรคุณ สำหรับการเปลี่ยนแปลงตามปกติ ให้หลีกเลี่ยงการใช้ CREATE OR REPLACE SECURITY INTEGRATION การแทนที่การรวมระบบอาจทำให้การเชื่อมต่อที่มีอยู่หยุดชะงักได้

หากต้องการตรวจสอบการรวมระบบโดยไม่แสดงรหัสลับ ให้เรียกใช้:

ยืนยันว่าการรวมระบบเปิดใช้งานอยู่ URI การเปลี่ยนเส้นทางตรงกันทุกประการ บทบาทได้รับอนุญาตและไม่ถูกบล็อก โทเค็นรีเฟรชและ PKCE เปิดใช้งานอยู่ และทั้งปลายทางการอนุญาตและปลายทางโทเค็นใช้โฮสต์บัญชีสาธารณะของ Snowflake

ขั้นตอนนี้จำเป็นเฉพาะในกรณีที่องค์กรของคุณกำหนดให้มีนโยบายเครือข่ายเท่านั้น โปรดขอให้ผู้รับผิดชอบด้านความปลอดภัยหรือเครือข่ายของคุณอนุมัติช่วงที่อยู่ IP ขาออกปัจจุบันของ Notion

การรวมระบบ OAuth ต้องอนุญาตเส้นทางของ Notion ทั้งสองเส้นทาง:

  1. เส้นทาง API ที่จัดการการเรียกกลับ OAuth และการแลกเปลี่ยนรหัสการอนุญาต

  2. เส้นทางรันไทม์ของพื้นที่ทำงานที่ตรวจสอบการเชื่อมต่อ เรียกใช้เครื่องมือ และรีเฟรชโทเค็น

เส้นทางเหล่านี้อาจใช้ที่อยู่ IP ขาออกของ Notion ต่างกัน หากคุณอนุญาตเฉพาะที่อยู่ที่ใช้ระหว่างการแลกเปลี่ยนโทเค็นครั้งแรก การลงชื่อเข้าใช้อาจสำเร็จ แต่การตรวจสอบหรือการรีเฟรชโทเค็นอาจล้มเหลว โปรดใช้ช่วงที่อยู่ IP ขาออกปัจจุบันของ Notion ที่ได้รับการอนุมัติแล้ว ห้ามเพิ่มที่อยู่ IP ที่พบเพียงครั้งเดียวในเบราว์เซอร์หรือบันทึกลงในลิสต์ที่อนุญาตของระบบการผลิต

แนบนโยบายเครือข่ายนี้เข้ากับการรวม OAuth ไม่ใช่กับผู้ใช้แต่ละราย อย่าเปลี่ยนนโยบายระดับบัญชีของคุณสำหรับการลงชื่อเข้าใช้เบราว์เซอร์ การเข้าถึง VPN หรือการเข้าถึงเครือข่ายของผู้ใช้ หากนโยบายเครือข่ายบล็อกคำขอโทเค็น Snowflake อาจส่งคืน invalid_client ข้อผิดพลาดนี้ไม่ได้หมายความว่ารหัสไคลเอ็นต์หรือรหัสลับไม่ถูกต้องเสมอไป

เรียกใช้คำสั่งนี้ในเวิร์กชีต Snowflake ที่ปลอดภัย ชื่อการรวมระบบต้องตรงตามตัวพิมพ์เล็ก-ใหญ่ และโดยปกติจะเป็นตัวพิมพ์ใหญ่:

แชร์รหัสไคลเอ็นต์และรหัสลับที่ตรงกันกับผู้ดูแลพื้นที่ทำงาน Notion ของคุณผ่านช่องทางที่ปลอดภัยซึ่งได้รับอนุมัติแล้ว Snowflake มีรหัสลับที่ใช้ได้สองชุด คุณจึงสามารถสลับใช้รหัสลับได้โดยไม่ต้องหยุดให้บริการ ห้ามวางรหัสลับทั้งสองชุดในเอกสาร แชท ทิกเก็ต หรือระบบควบคุมเวอร์ชันของซอร์สโค้ดเด็ดขาด

การเชื่อมต่อ MCP ที่กำหนดค่าในพื้นที่ทำงานเป็นฟีเจอร์ที่อยู่ในช่วงอัลฟ่าในขณะนี้

หากพื้นที่ทำงานยังไม่มีสิทธิ์เข้าถึง โปรดติดต่อทีมดูแลลูกค้าหรือสมัครเข้าร่วมโปรแกรมการเข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูลของเรา

เมื่อ Snowflake พร้อมแล้ว เจ้าของหรือผู้ดูแลพื้นที่ทำงานจะเพิ่มเซิร์ฟเวอร์หนึ่งครั้งสำหรับพื้นที่ทำงาน จากนั้นสมาชิกจะค้นหาเซิร์ฟเวอร์ได้โดยไม่ต้องเห็นรหัสลับไคลเอ็นต์ OAuth ไม่ว่าจะเชื่อมต่อ Snowflake MCP กับเอเจนต์ที่กำหนดเองหรือ Notion Agent ของตนเองก็ตาม

  1. ไปที่ การตั้งค่า ของพื้นที่ทำงาน

  2. เลือก การเชื่อมต่อ → MCP ที่แชร์ในพื้นที่ทำงาน

  3. เลือก MCP พื้นที่ทำงานใหม่

กรอกข้อมูลในฟิลด์เหล่านี้ จากนั้นเลือก เพิ่มเซิร์ฟเวอร์ MCP:

ฟิลด์

สิ่งที่ต้องป้อน

ชื่อ

ชื่อที่ชัดเจนซึ่งสมาชิกมองเห็นได้ เช่น Company Snowflake Data Agent

คำอธิบาย

โน้ตสั้นๆ เกี่ยวกับข้อมูลและวัตถุประสงค์ในการใช้งาน

URL เซิร์ฟเวอร์

URL สาธารณะของ Snowflake MCP ที่ตรงตามที่ระบุในเวิร์กชีตทุกประการ

กำหนดค่าการยืนยันตัวตนด้วยตนเอง

เปิดใช้งาน Notion จะตรวจพบรายละเอียด OAuth ของ Snowflake

ใช้ไคลเอ็นต์ OAuth ที่แชร์ในพื้นที่ทำงาน

เปิดใช้งาน

URI การเปลี่ยนเส้นทาง

สร้างโดย Notion ยืนยันว่า URI นี้ตรงกับ URI ที่คุณให้ไว้กับผู้ดูแล Snowflake

รหัสไคลเอ็นต์

รหัสไคลเอ็นต์จากการรวมระบบ OAuth ของ Snowflake

รหัสลับไคลเอ็นต์

รหัสลับที่ตรงกับรหัสไคลเอ็นต์ ซึ่งได้รับผ่านช่องทางที่ปลอดภัยและได้รับอนุมัติแล้ว

ขอบเขต OAuth

เลือกขอบเขต session:role:<mcp_access_role> ให้ตรงทุกประการ ใช้ All scopes ได้ก็ต่อเมื่อ Snowflake ระบุว่ารองรับเฉพาะขอบเขตที่อนุมัติแล้วนี้ และไม่มีขอบเขตอื่นที่กว้างกว่า

หลังจากบันทึกแล้ว ให้ยืนยันว่าแถวใหม่ปรากฏขึ้นภายใต้ Shared with this workspace และ Workspace OAuth client แสดงสถานะ Configured

ผลของการตั้งค่านี้:

  • ช่วยให้สมาชิกพบเซิร์ฟเวอร์ที่อนุมัติแล้ว

  • จัดเก็บข้อมูลลับของไคลเอ็นต์ OAuth ไว้ในที่จัดเก็บการเชื่อมต่อที่เข้ารหัสของ Notion หนึ่งครั้ง

  • ช่วยให้แน่ใจว่าสมาชิกลงชื่อเข้าใช้ด้วย URL ของเซิร์ฟเวอร์ ไคลเอ็นต์ และขอบเขตสิทธิ์ที่อนุมัติไว้

  • ไม่สร้างเซสชัน Snowflake ที่แชร์หรือข้ามการควบคุมการเข้าถึงของ Snowflake

  • ไม่เชื่อมต่อสมาชิกทุกคนโดยอัตโนมัติ แต่ละคนต้องลงชื่อเข้าใช้แยกต่างหาก

หากคุณลบการตั้งค่านี้ สมาชิกใหม่จะไม่สามารถค้นหาเซิร์ฟเวอร์ได้อีกต่อไป การเชื่อมต่อที่มีอยู่อาจยังคงปรากฏอยู่ ดังนั้นโปรดประสานงานการเปลี่ยนแปลงนี้กับการเพิกถอนสิทธิ์ของ Snowflake และการลบการเชื่อมต่อที่มีอยู่

เมื่อผู้ดูแลเตรียมการเชื่อมต่อ Snowflake MCP พร้อมแล้ว ก็ใช้งานได้ 2 วิธี หากตั้งค่าให้ทีม ให้เริ่มที่ 11A หากต้องการถามคำถามของตัวเอง ให้ข้ามไปที่ 11B จะใช้ทั้ง 2 วิธีด้วยก็ได้ เพราะเป็นการเชื่อมต่อแยกกัน

ขั้นตอนที่ 11A: ตั้งค่าเอเจนต์ที่กำหนดเองซึ่งจัดการให้ทีม

เอเจนต์ที่กำหนดเองช่วยให้ทีมของคุณมีที่เดียวสำหรับสอบถามข้อมูล Snowflake คุณเชื่อมต่อ Snowflake เพียงครั้งเดียว เพิ่มคำสั่งเกี่ยวกับเมตริกและตารางของคุณ แล้วแชร์เอเจนต์กับทีมของคุณ ทุกคนที่ใช้งานจะต้องลงชื่อเข้าใช้ Snowflake ด้วยข้อมูลประจำตัวของตนเอง ดังนั้นแต่ละคนจะได้รับคำตอบตามข้อมูลที่ตนได้รับอนุญาตให้เห็นเท่านั้น

การยืนยันตัวตนรายบุคคลในเอเจนต์ที่กำหนดเองกำลังอยู่ในช่วงอัลฟ่า

หากพื้นที่ทำงานยังไม่มีสิทธิ์เข้าถึง โปรดติดต่อทีมดูแลลูกค้าหรือสมัครเข้าร่วมโปรแกรมการเข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูลของเรา

เชื่อมต่อ Snowflake เข้ากับเอเจนต์ที่กำหนดเอง

  1. เปิดเอเจนต์ที่กำหนดเอง หรือ สร้างเอเจนต์ใหม่

  2. ไปที่ การตั้งค่า → เครื่องมือและการเข้าถึง

  3. เลือก เพิ่มการเชื่อมต่อ จากนั้นเลือกเซิร์ฟเวอร์ Snowflake ที่มีป้ายกำกับว่า Workspace Managed อย่าเลือก Custom MCP server หรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเอง

  4. ลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงการลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรของคุณ

  5. ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ

  6. เลือกเครื่องมือที่เอเจนต์ใช้ได้ ตั้งค่าเครื่องมือที่เขียนข้อมูลได้และ CORTEX_AGENT_RUN ให้ขออนุมัติไว้ก่อน จนกว่าจะทดสอบเรียบร้อย

  7. เลือก เชื่อมต่อ และยืนยันว่าการเชื่อมต่อแสดงเป็น เชื่อมต่อแล้ว

ให้บริบทแก่เอเจนต์

การเชื่อมต่อนี้ช่วยให้เอเจนต์เข้าถึง Snowflake ได้ คำสั่งของคุณจะบอกเอเจนต์ว่าบริษัทของคุณใช้ข้อมูลนั้นอย่างไร ในคำสั่งของเอเจนต์ ให้ระบุว่าควรใช้เครื่องมือใดสำหรับคำถามประเภทใด ทีมของคุณกำหนดเมตริกหลักอย่างไร และควรเริ่มจากตารางหรือมุมมองเชิงความหมาย (semantic view) ใด ตัวอย่างคำถามที่ผ่านการตรวจสอบแล้วเพียงไม่กี่ข้อก็ช่วยได้มาก สำหรับจุดเริ่มต้นที่พร้อมใช้งาน โปรดดูคู่มือชุดเครื่องมือ Data Scout

แชร์เอเจนต์

แชร์เอเจนต์กับทีมเหมือนที่แชร์เอเจนต์ที่กำหนดเองตัวอื่น เมื่อมีคนถามคำถามที่ต้องใช้ Snowflake เป็นครั้งแรก ระบบจะขอให้คนนั้นลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของตัวเอง โดยไม่ต้องป้อน ID ไคลเอ็นต์หรือรหัสลับ

การยืนยันตัวตนรายบุคคลมีผลเมื่อมีคนแชทกับเอเจนต์โดยตรง

รอบการทำงานตามกำหนดการและรอบการทำงานที่เริ่มเมื่อมีเหตุการณ์กระตุ้นไม่มีผู้ลงชื่อเข้าใช้ จึงยังใช้สิทธิ์เข้าถึง Snowflake ของใครไม่ได้ หากต้องการใช้ข้อมูล Snowflake ตามกำหนดการ ให้ปรึกษาผู้ดูแล Snowflake ก่อนตั้งค่า

ขั้นตอนที่ 11B: เชื่อมต่อ Snowflake เข้ากับ Notion Agent ของคุณเอง

หากคุณต้องการถามคำถามของคุณเองในการแชทของคุณเอง ให้เชื่อมต่อ Snowflake เข้ากับ Notion Agent ของคุณ คุณลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของคุณเอง ดังนั้นเอเจนต์ของคุณจะเข้าถึงได้เฉพาะสิ่งที่คุณได้รับอนุญาตให้เห็นเท่านั้น

  1. ไปที่ การตั้งค่า → Notion AI

  2. ภายใต้ เซิร์ฟเวอร์ MCP ให้เลือก เพิ่มเซิร์ฟเวอร์ MCP

  3. เลือกเซิร์ฟเวอร์ Snowflake ที่มีป้ายกำกับว่า Workspace Managed อย่าเลือก Custom MCP server หรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเอง

  4. เลือก เชื่อมต่อ

  5. ลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงการลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรของคุณ

  6. ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ

  7. เมื่อเบราว์เซอร์ของคุณถามว่าจะเปิด Notion หรือไม่ ให้เลือก เปิด Notion

  8. ยืนยันว่าสถานะเซิร์ฟเวอร์คือ เชื่อมต่อแล้ว ไม่ใช่ ต้องการการยืนยันตัวตน

หลังจากที่คุณเชื่อมต่อแล้ว Snowflake จะปรากฏใน แหล่งข้อมูลทั้งหมด → เซิร์ฟเวอร์ MCP ในแชท

คุณไม่ควรถูกขอให้ระบุรหัสไคลเอนต์ OAuth หรือข้อมูลลับของไคลเอนต์ไม่ว่าจะใช้วิธีใด

หาก Notion ขอข้อมูลอย่างใดอย่างหนึ่ง คุณอาจเลือกตัวเลือก MCP แบบกำหนดเองแทนเซิร์ฟเวอร์ที่จัดการโดยพื้นที่ทำงาน หรือผู้ดูแลของคุณอาจยังไม่ได้เปิด ใช้ไคลเอนต์ OAuth ที่แชร์ร่วมกันในพื้นที่ทำงาน ให้ย้อนกลับไปเลือกเซิร์ฟเวอร์ จัดการโดยพื้นที่ทำงาน แทน

  1. ถามคำถามที่ไม่เป็นอันตรายซึ่งทราบคำตอบอยู่แล้วและควรใช้ Snowflake ในการตอบ

  2. ยืนยันว่าเอเจนต์ใช้ Snowflake และส่งคืนผลลัพธ์

  3. ยืนยันว่าเข้าถึงข้อมูลที่อยู่นอกเหนือสิทธิ์ของบทบาทที่ได้รับไม่ได้

หากตั้งค่าเอเจนต์ที่กำหนดเองไว้ ให้เพื่อนร่วมทีมที่มีสิทธิ์ตามบทบาท Snowflake จำกัดกว่าลองใช้ด้วย เพื่อนร่วมทีมควรเห็นเฉพาะข้อมูลที่ตัวเองมีสิทธิ์เข้าถึง ไม่ใช่ข้อมูลที่ผู้สร้างเอเจนต์มีสิทธิ์เข้าถึง นี่เป็นวิธีที่เร็วที่สุดในการยืนยันว่าเอเจนต์ใช้สิทธิ์การเข้าถึงของแต่ละคน ไม่ใช่ของผู้สร้างเอเจนต์

สำหรับการตรวจสอบเชิงลึก ให้ขอให้ผู้ดูแลระบบ Snowflake ของคุณยืนยันผู้ใช้ บทบาท คลังข้อมูล และประวัติการสืบค้นของคุณ การลงชื่อเข้าใช้สำเร็จเป็นการยืนยันตัวตนของคุณ แต่ไม่ได้ยืนยันว่าการให้สิทธิ์ทุกอย่างถูกต้อง

ถามคำถามเฉพาะเจาะจงเกี่ยวกับข้อมูล Snowflake ของคุณกับเอเจนต์ ตัวอย่างเช่น:

  • "จาก Snowflake ยอดการสมัครใช้งานทั้งหมดของเราเมื่อเดือนที่แล้วคือเท่าไร"

  • "จาก Snowflake บัญชี 10 อันดับแรกที่สร้างรายได้สูงสุดให้เราในไตรมาสนี้มีบัญชีใดบ้าง"

สำหรับเอเจนต์ที่กำหนดเอง คุณมักจะข้ามคำว่า "จาก Snowflake" ได้เมื่อคำสั่งของเอเจนต์ระบุชัดเจนว่าควรใช้เมื่อใด สำหรับ Notion Agent ของคุณ การระบุชื่อ Snowflake จะช่วยให้เอเจนต์เลือกแหล่งข้อมูลที่ถูกต้องได้

คำขอที่มีขอบเขตกว้างอาจใช้เวลานานขึ้นหรือหมดเวลา หากเกิดเหตุการณ์ดังกล่าว ให้ถามคำถามที่เจาะจงขึ้นหรือแบ่งคำขอออกเป็นคำถามย่อย ๆ

โดยส่วนใหญ่ การเชื่อมต่อจะยังคงอยู่โดยไม่ต้องทำอะไร Snowflake ใช้โทเค็นการเข้าถึงที่มีอายุสั้น และ Notion จะรีเฟรชโทเค็นในเบื้องหลัง แค่โทเค็นการเข้าถึงใกล้หมดอายุก็ไม่ทำให้การเชื่อมต่อหลุด

ต้องลงชื่อเข้าใช้อีกครั้งหาก:

  • รีเฟรชโทเค็นของคุณหมดอายุหรือผู้ดูแลเพิกถอนโทเค็นนั้น

  • ผู้ดูแลเปลี่ยนการผสานการทำงาน OAuth หรือรหัสลับของไคลเอ็นต์

  • บทบาท Snowflake ของคุณถูกลบออก

  • ผู้ดูแลนำการตั้งค่าพื้นที่ทำงานหรือการเชื่อมต่อออก

  • นโยบายเครือข่ายบล็อกการรีเฟรชโทเค็น

เอเจนต์ที่กำหนดเองจะแยกการลงชื่อเข้าใช้ของแต่ละคน หากมีคนต้องลงชื่อเข้าใช้อีกครั้ง ก็จะไม่กระทบคนอื่น และคนที่สร้างเอเจนต์ก็ไม่ต้องทำอะไร

หากกำลังเปลี่ยนรหัสลับของไคลเอ็นต์: ให้ใช้วิธีหมุนเวียนรหัสลับ 2 ชุดของ Snowflake แทนการเปลี่ยนการผสานการทำงาน คงรหัสลับทั้ง 2 ชุดให้ใช้ได้จนกว่าจะอัปเดตและทดสอบการตั้งค่าพื้นที่ทำงานเสร็จ แล้วจึงเลิกใช้รหัสลับชุดเก่า

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

  • การเชื่อมต่อ Snowflake MCP ไม่อยู่ในลิสต์ ผู้ดูแลพื้นที่ทำงานอาจยังไม่ได้เพิ่มการเชื่อมต่อนี้ หรือพื้นที่ทำงานอาจจำกัดการใช้เซิร์ฟเวอร์แบบกำหนดเอง ขอความช่วยเหลือจากผู้ดูแล

  • ระบบขอรหัสไคลเอ็นต์หรือรหัสลับ อาจเลือกตัวเลือก MCP แบบกำหนดเองไว้ ให้ย้อนกลับไปเลือกเซิร์ฟเวอร์ Snowflake ที่มีป้าย Workspace Managed แทน

  • ระบบขอให้ลงชื่อเข้าใช้อีกครั้ง เซสชัน Snowflake อาจหมดอายุ หรือผู้ดูแลอาจอัปเดตการเชื่อมต่อ ให้ลงชื่อเข้าใช้ Snowflake อีกครั้ง

  • เปิดเอเจนต์ที่กำหนดเองแล้วระบบขอให้ลงชื่อเข้าใช้ Snowflake เป็นเรื่องปกติเมื่อใช้งานครั้งแรก ทุกคนที่ใช้เอเจนต์ที่กำหนดเองแบบมีการจัดการต้องลงชื่อเข้าใช้ด้วยข้อมูลประจำตัว Snowflake ของตนเอง

  • เพื่อนร่วมทีมได้ผลลัพธ์ต่างกันจากเอเจนต์ที่กำหนดเองตัวเดียวกัน เป็นเรื่องปกติ เพราะเอเจนต์ใช้สิทธิ์เข้าถึง Snowflake ของแต่ละคน คนที่มีบทบาทต่างกันจึงเห็นข้อมูลต่างกัน

  • เอเจนต์ที่กำหนดเองใช้ได้ในแชท แต่ไม่ทำงานตามกำหนดการ รอบการทำงานตามกำหนดการและรอบการทำงานที่เริ่มจากเหตุการณ์ไม่มีคนลงชื่อเข้าใช้ จึงยังใช้ Snowflake ที่ต้องลงชื่อเข้าใช้แยกกันแต่ละคนไม่ได้

  • ลงชื่อเข้าใช้แล้ว แต่เชื่อมต่อไม่ได้หรือเครื่องมือทำงานไม่สำเร็จ การลงชื่อเข้าใช้ยืนยันตัวตนได้ แต่สิทธิ์เข้าถึงยังขึ้นอยู่กับสิทธิ์ที่ได้รับใน Snowflake ขอให้ผู้ดูแล Snowflake ตรวจสอบว่าบทบาทเข้าถึงเซิร์ฟเวอร์ คลังข้อมูล เอเจนต์ และข้อมูลได้หรือไม่

  • เอเจนต์หาตารางไม่พบ เอเจนต์เข้าถึงได้เฉพาะข้อมูลที่บัญชี Snowflake เข้าถึงได้ ตรวจสอบสิทธิ์ใน Snowflake และระบุชื่อตารางในคำถาม

  • คำขอหมดเวลา ลองถามให้เจาะจงขึ้น หรือแบ่งคำขอเป็นคำถามย่อย

สำหรับผู้ดูแล: ข้อผิดพลาดในการลงชื่อเข้าใช้และการเชื่อมต่อ

ข้อผิดพลาดเหล่านี้มักเกิดจากการตั้งค่า Snowflake ไม่ใช่ Notion ส่งรายละเอียดให้ผู้ดูแล Snowflake ตรวจสอบ

  • URL ของเซิร์ฟเวอร์ดูเหมือนซ้ำกัน เช่น https://https%3A... ที่อยู่ถูกวางโดยมี https:// เกินมาด้านหน้า โปรดแก้ไขเพื่อให้ URL ขึ้นต้นด้วย https:// เพียงชุดเดียว

  • เห็นข้อความ "This server does not support OAuth authentication." อาจไม่ได้ตั้งค่าการผสานการทำงานด้านความปลอดภัยสำหรับ OAuth หรือ URL ของเซิร์ฟเวอร์อาจไม่ถูกต้อง ขอให้ผู้ดูแล Snowflake ตรวจสอบทั้ง 2 จุด

  • เห็น invalid_client ขณะลงชื่อเข้าใช้หรือรีเฟรช รหัสไคลเอ็นต์หรือรหัสลับอาจไม่ถูกต้อง หรือรหัสลับถูกเปลี่ยนไปแล้ว ขอรหัสไคลเอ็นต์และรหัสลับปัจจุบันจากผู้ดูแล

  • ลงชื่อเข้าใช้ได้ แต่ใช้งานไม่ได้ทันทีหลังจากนั้น บทบาทอาจเข้าถึงเซิร์ฟเวอร์ไม่ได้ หรือบทบาทหรือกฎเครือข่ายอาจบล็อกเซสชัน ขอให้ผู้ดูแลตรวจสอบสิทธิ์และนโยบาย

  • เห็นข้อความ "The role ALL requested has been explicitly blocked." การเชื่อมต่อขอใช้ทุกบทบาทพร้อมกัน (session:role:all) ซึ่งถูกบล็อกไว้ ให้ระบุบทบาทจริงเพียงบทบาทเดียวแทน เช่น session:role:analyst

  • เห็นข้อผิดพลาดในการเปลี่ยนเส้นทาง (ข้อผิดพลาด 390307) URL สำหรับเปลี่ยนเส้นทางที่บันทึกใน Snowflake ไม่ตรงกับ URL ที่ Notion ใช้ ขอให้ผู้ดูแลตั้งค่า URL สำหรับเปลี่ยนเส้นทางในการผสานการทำงานด้านความปลอดภัยให้ตรงกับค่าของ Notion ทุกประการ

  • เห็นข้อผิดพลาด 390311 เกี่ยวกับค่า code challenge ที่ไม่ถูกต้อง ค่า PKCE ไม่ตรงกัน ขอให้ผู้ดูแลตรวจสอบว่าตั้งค่า OAUTH_ENFORCE_PKCE ในการผสานการทำงานด้านความปลอดภัยถูกต้องหรือไม่

  • เชื่อมต่อแล้ว แต่ไม่เห็นเครื่องมือ บทบาทอาจไม่มีสิทธิ์ USAGE บนเซิร์ฟเวอร์ MCP ขอให้ผู้ดูแลตรวจสอบสิทธิ์ จากนั้นเรียกใช้ DESCRIBE MCP SERVER เพื่อตรวจสอบการตั้งค่า

  • เข้าถึงข้อมูลได้มากหรือน้อยกว่าที่คาดไว้ บทบาทรองมีผลต่อข้อมูลที่มองเห็นในเซสชัน ตรวจสอบกับผู้ดูแลว่าบทบาทใดเปิดใช้งานอยู่ในเซสชัน

  • ก่อนหน้านี้ใช้ได้ แต่หลังเปลี่ยนรหัสลับ ทุกคนก็ใช้ไม่ได้ รหัสลับของไคลเอ็นต์ถูกเปลี่ยนแล้ว ข้อมูลการเชื่อมต่อที่บันทึกไว้จึงล้าสมัย ขอรหัสลับใหม่จากผู้ดูแล แล้วเชื่อมต่ออีกครั้ง

  • ก่อนหน้านี้ใช้ได้ แต่ตอนนี้ใช้ไม่ได้อยู่คนเดียว บทบาท สิทธิ์ หรือนโยบายอาจเปลี่ยนไป หรือเซสชันอาจหมดอายุ ลงชื่อเข้าใช้อีกครั้ง แล้วขอให้ผู้ดูแลตรวจสอบว่าสิทธิ์เข้าถึงไม่ได้เปลี่ยนไป

  • ตัวระบุบัญชีของคุณถูกปฏิเสธ โปรดใช้รูปแบบ organization-account ที่มีเครื่องหมายยัติภังค์ เช่น myorg-myaccount ไม่ใช่จุด

  • บัญชี PrivateLink เชื่อมต่อไม่ได้ บัญชี PrivateLink ต้องตั้งค่าเครือข่ายเพิ่มเติม สอบถามผู้ดูแลว่า PrivateLink อนุญาตให้เชื่อมต่อกับ Notion หรือไม่

  • Snowflake ใช้ไม่ได้ในรอบการทำงานตามกำหนดการหรือรอบการทำงานที่เริ่มเมื่อมีเหตุการณ์กระตุ้น รอบการทำงานเหล่านี้ไม่มีผู้ลงชื่อเข้าใช้ จึงยังใช้การลงชื่อเข้าใช้แบบรายบุคคลไม่ได้ ให้ส่งคำขอผ่านแชทแทน

  • คุณเห็น oauth_security_error หลังจากลงชื่อเข้าใช้ผ่านเบราว์เซอร์ นโยบายเครือข่ายระดับบัญชีอาจกำลังบล็อกคำขอนี้ ผู้ดูแลของคุณสามารถตรวจสอบได้โดยเรียกใช้:

  • ดูเหมือนว่าการลงชื่อเข้าใช้จะสำเร็จ แต่คุณได้รับข้อผิดพลาดเกี่ยวกับบทบาท แม้จะระบุขอบเขตที่ถูกต้องแล้วก็ตาม บทบาทเริ่มต้นของคุณอาจถูกบล็อก เช่น ACCOUNTADMIN หรือบทบาทใน BLOCKED_ROLES_LIST ผู้ดูแลของคุณสามารถตรวจสอบและแก้ไขได้ดังนี้:

คำสั่งแบบอ่านอย่างเดียวเหล่านี้ช่วยให้ผู้ดูแลของคุณตรวจสอบการตั้งค่าได้โดยไม่เปลี่ยนแปลงสิ่งใด โปรดเรียกใช้คำสั่งเหล่านี้ใน Snowflake

มุมมอง ACCOUNT_USAGE อาจแสดงข้อมูลล่าช้า ดังนั้นการไม่พบแถวข้อมูลจึงไม่ได้พิสูจน์ว่าไม่เคยมีคำขอเกิดขึ้น

อย่าเพิ่งเปลี่ยนข้อมูลลับ ลดความเข้มงวดของนโยบาย หรือขยายสิทธิ์ที่ให้ไว้จนกว่าจะรู้ว่าปัญหาเกิดขึ้นที่ส่วนใด

ใช้คู่มือ Snowflake เหล่านี้เพื่อดำเนินการตั้งค่าให้เสร็จสมบูรณ์:

คำถามที่พบบ่อย

ควรตั้งค่าเอเจนต์ที่กำหนดเองหรือเชื่อมต่อ Snowflake กับ Notion Agent ดี?

หากตั้งค่าการเชื่อมต่อ Snowflake MCP ให้ทีม ให้สร้างเอเจนต์ที่กำหนดเอง เพื่อให้ทุกคนใช้คำสั่งและคำจำกัดความของตัวชี้วัดชุดเดียวกัน และมีที่เดียวสำหรับถามคำถาม โดยแต่ละคนยังลงชื่อเข้าใช้ด้วยข้อมูลประจำตัว Snowflake ของตนเอง หากต้องการถามคำถามของตัวเองเท่านั้น ให้เชื่อมต่อ Snowflake MCP กับ Notion Agent จะทำทั้งสองอย่างก็ได้

ถ้าเชื่อมต่อ Snowflake กับ Notion Agent แล้ว Snowflake จะเชื่อมต่อกับเอเจนต์ที่กำหนดเองของทีมด้วยไหม?

ไม่ การเชื่อมต่อแต่ละรายการแยกจากกัน และเอเจนต์ที่กำหนดเองแต่ละตัวต้องมีการเชื่อมต่อของตัวเอง การตั้งค่า Snowflake ในขั้นตอนที่ 1–10 ใช้ร่วมกันได้ แต่ต้องลงชื่อเข้าใช้แยกกัน

ทุกคนในทีมเห็นข้อมูลเดียวกันไหม?

ไม่ แต่ละคนลงชื่อเข้าใช้ Snowflake ด้วยข้อมูลประจำตัวของตนเอง เอเจนต์จึงเข้าถึงได้เฉพาะข้อมูลที่บัญชีของคนนั้นเข้าถึงได้ เอเจนต์ที่กำหนดเองก็เช่นกัน

ต้องแชร์รหัสผ่าน Snowflake กับทีมไหม?

ไม่ ไม่มีใครแชร์ข้อมูลประจำตัว พื้นที่ทำงานจะจัดเก็บรายละเอียดไคลเอ็นต์ OAuth ไว้เพียงครั้งเดียว และแต่ละคนจะลงชื่อเข้าใช้ Snowflake ด้วยตนเอง

ให้ข้อเสนอแนะ

แหล่งข้อมูลนี้มีประโยชน์หรือไม่?