Power Platform Governance — ปิดประตู Shadow Automation ก่อนข้อมูลรั่วไหล ด้วย DLP Policy

บทนำ: เมื่อ Low-Code กลายเป็นดาบสองคม

ในยุคที่ Microsoft Power Platform ได้รับความนิยมอย่างแพร่หลายในองค์กรไทย ไม่ว่าจะเป็น Power Apps, Power Automate หรือ Power BI ผู้ใช้งานทั่วไปสามารถสร้าง Application และ Automation ได้เองโดยไม่ต้องรอทีม IT อีกต่อไป ฟังดูดีใช่ไหม? แต่นั่นคือจุดเริ่มต้นของปัญหาที่เรียกว่า Shadow Automation — การที่พนักงานสร้าง Flow หรือ App ที่ดึงข้อมูลสำคัญขององค์กรออกไปยังบริการภายนอกโดยที่ IT ไม่รู้เรื่อง

ลองจินตนาการว่ามีพนักงานแผนก HR สร้าง Power Automate Flow ที่ส่งข้อมูลพนักงานทั้งหมดไปยัง Google Sheets หรือ Dropbox โดยอัตโนมัติทุกวัน หรือฝ่ายขายที่ Connect ข้อมูล CRM ไปยัง Third-party Service โดยไม่ผ่านการอนุมัติ สิ่งเหล่านี้ไม่ใช่เรื่องสมมติ แต่เกิดขึ้นจริงในหลายองค์กรทั่วโลก รวมถึงในประเทศไทย

บทความนี้จะพาคุณทำความเข้าใจกับ Data Loss Prevention (DLP) Policy ใน Power Platform ซึ่งเป็นเครื่องมือหลักในการวาง Governance ป้องกัน Shadow Automation และรักษาความปลอดภัยของข้อมูลองค์กร โดยไม่ต้องปิดกั้นความสามารถในการใช้งานของผู้ใช้ทั้งหมด

Shadow Automation คืออะไร และทำไมถึงอันตราย

Shadow Automation หมายถึง Workflow, Application หรือ Integration ที่พนักงานสร้างขึ้นเองโดยไม่ผ่านกระบวนการ IT Governance หรือการอนุมัติจากองค์กร ความอันตรายมีหลายมิติ ได้แก่:

• Data Leakage: ข้อมูลลูกค้า ข้อมูลการเงิน หรือข้อมูล HR ถูกส่งออกไปยัง External Service โดยไม่ได้รับอนุญาต
• Compliance Violation: ละเมิด PDPA, ISO 27001 หรือมาตรฐานความปลอดภัยที่องค์กรยึดถือ
• Uncontrolled Connector Usage: พนักงานใช้ Connector กับบริการที่ไม่ได้รับการตรวจสอบ เช่น Personal Gmail, Twitter หรือ WhatsApp
• License Cost Overrun: การใช้ Premium Connector โดยไม่ได้วางแผน ทำให้ค่า License บานปลาย
• Single Point of Failure: เมื่อเจ้าของ Flow ลาออก ไม่มีใครรู้ว่า Automation นั้นทำงานอะไรอยู่บ้าง

ทำความรู้จัก DLP Policy ใน Power Platform

Data Loss Prevention Policy คือนโยบายที่ Power Platform Admin กำหนดขึ้นเพื่อควบคุมว่า Connector ใดบ้างที่สามารถทำงานร่วมกันได้ภายใน Flow หรือ App เดียวกัน โดยแบ่ง Connector ออกเป็น 3 กลุ่ม:

• Business Group: Connector ที่อนุญาตให้ใช้กับข้อมูลธุรกิจ เช่น SharePoint, Dataverse, Teams, Outlook
• Non-Business Group: Connector ที่จัดว่าเป็น Personal Use หรือไม่เหมาะกับข้อมูลสำคัญ เช่น Twitter, Instagram
• Blocked Group: Connector ที่ถูกบล็อกทั้งหมด ห้ามใช้งานเด็ดขาด

หลักการสำคัญคือ Connector จาก Business Group และ Non-Business Group ไม่สามารถอยู่ใน Flow เดียวกันได้ ซึ่งป้องกันการส่งข้อมูลจากระบบธุรกิจไปยังบริการ Personal โดยตรง

วิธีตั้งค่า DLP Policy แบบ Step-by-Step

1. เข้า Power Platform Admin Center

ไปที่ admin.powerplatform.microsoft.com แล้วเลือก Policies > Data policies จากนั้นกด New policy

2. กำหนด Scope ของ Policy

• Add all environments: ใช้กับทุก Environment ในองค์กร (แนะนำสำหรับ Default Policy)
• Add multiple environments: เลือกเฉพาะ Environment ที่ต้องการ เช่น Production เท่านั้น
• Exclude certain environments: ยกเว้น Sandbox หรือ Dev Environment เพื่อให้ Developer มีอิสระมากขึ้น

3. จัดกลุ่ม Connector

ย้าย Connector ที่อนุมัติแล้วเข้า Business Group เช่น SharePoint, Exchange, Teams, Dataverse, Azure Services ส่วน Connector อื่นที่ไม่ต้องการให้ใช้ร่วมกับข้อมูลธุรกิจ ให้ย้ายเข้า Non-Business หรือ Blocked

4. ตั้งค่า Custom Connector Policy

อย่าลืม Custom Connector ที่ทีม Developer สร้างขึ้นเอง ควรกำหนดว่า Custom Connector Pattern ใดที่จัดอยู่ใน Group ไหน เพื่อป้องกันช่องโหว่

กลยุทธ์ Governance ที่ครบวงจร

DLP เพียงอย่างเดียวไม่เพียงพอ องค์กรควรมี Governance Framework ที่ครอบคลุมดังนี้:

• Environment Strategy: แบ่ง Environment ออกเป็น Default, Development, Test และ Production อย่างชัดเจน ห้ามสร้าง Production App ใน Default Environment
• CoE (Center of Excellence) Starter Kit: Microsoft มี CoE Toolkit ให้ดาวน์โหลดฟรี ช่วย Monitor การใช้งาน Power Platform ทั้งองค์กร เห็นได้ว่ามี Flow กี่ตัว, App กี่ตัว, ใครเป็นเจ้าของ
• Maker Policy: กำหนด Policy ว่าใครมีสิทธิ์สร้าง App ได้บ้าง ผ่าน Azure AD Group และ Environment Permission
• App Quarantine: ใช้ฟีเจอร์ Quarantine เพื่อระงับการใช้งาน App ที่ละเมิดนโยบายชั่วคราว ระหว่างรอการตรวจสอบ
• Regular Audit: ตั้ง Alert ผ่าน Microsoft 365 Compliance Center เมื่อมีการสร้าง Flow ที่ใช้ Connector นอก Approved List

เคล็ดลับจากประสบการณ์จริง (Practical Tips)

• เริ่มจาก Audit ก่อน Block: ก่อนบังคับใช้ DLP Policy ให้รัน CoE Dashboard ดูก่อนว่ามี Flow/App อะไรอยู่แล้วบ้าง เพราะถ้า Block ทันทีอาจทำให้ Business Process ที่ทำงานอยู่พัง
• สื่อสารกับ Business Unit: แจ้ง Maker ล่วงหน้าอย่างน้อย 30 วัน ก่อนบังคับใช้ Policy ใหม่ พร้อมให้ช่องทางยื่นขอ Exception
• ใช้ Environment-specific DLP: Policy สำหรับ Production ควรเข้มงวดกว่า Dev Environment เพื่อไม่ปิดกั้น Innovation
• Monitor HTTP Connector: HTTP และ HTTP with Azure AD Connector เป็นช่องโหว่ที่มักถูกมองข้าม ควร Block ใน Default Policy แล้วค่อยอนุญาตเป็น Case by Case
• Document Approved Connector List: จัดทำเอกสาร Approved Connector List และเผยแพร่ใน SharePoint เพื่อให้ Maker ทราบว่าใช้อะไรได้บ้างก่อนเริ่มสร้าง
• ใช้ Power Automate Desktop แยกต่างหาก: RPA Flow มักต้องการสิทธิ์พิเศษ ควรแยก Environment และ DLP Policy สำหรับ Desktop Flow โดยเฉพาะ

สรุป และ Call to Action

Power Platform เป็นเครื่องมือที่ทรงพลังมากสำหรับองค์กรยุคใหม่ แต่ความยืดหยุ่นนั้นมาพร้อมกับความเสี่ยงที่ต้องจัดการอย่างรอบคอบ DLP Policy คือกำแพงป้องกันชั้นแรกที่ทุก IT Admin ควรตั้งค่าตั้งแต่วันแรกที่เปิดใช้งาน Power Platform ในองค์กร ควบคู่ไปกับ Environment Strategy และ CoE Toolkit เพื่อให้มองเห็นและควบคุม Shadow Automation ได้อย่างมีประสิทธิภาพ

การ Govern ที่ดีไม่ได้หมายความว่าต้อง "ปิดกั้นทุกอย่าง" แต่คือการ เปิดพื้นที่ที่ปลอดภัยให้ Innovation เกิดขึ้นได้ โดยยังคงปกป้องข้อมูลสำคัญขององค์กรไว้ได้ในเวลาเดียวกัน

Action Items สำหรับสัปดาห์นี้:

• ✅ เข้า Power Platform Admin Center และตรวจสอบ DLP Policy ปัจจุบันของคุณ
• ✅ ดาวน์โหลด CoE Starter Kit จาก Microsoft และติดตั้งใน Dedicated Environment
• ✅ จัดประชุม Workshop กับ Power Platform Maker ในองค์กรเพื่อสื่อสาร Governance Policy
• ✅ Review Connector List และกำหนด Approved vs Blocked Connector อย่างเป็นทางการ

หากคุณมีคำถามเพิ่มเติมเกี่ยวกับการวาง Power Platform Governance หรือต้องการแชร์ประสบการณ์ ฝากคอมเมนต์ไว้ได้เลยครับ แล้วพบกันในบทความหน้า! 🚀