วิธีปฏิเสธการเข้าถึง SQL Server เพื่อเข้าสู่ระบบบางอย่างผ่าน SSMS แต่อนุญาตผ่าน. Net SqlClient Data Provider

เรามีสถานการณ์ที่นักพัฒนาไม่ได้UPDATEรับอนุญาตใด ๆแต่พวกเขาทำงานกับแอปพลิเคชันและดูสตริงการเชื่อมต่อ -> พวกเขารู้รหัสผ่านจากบัญชี SQL บางบัญชี (ตัวอย่างSQLLogin1) ที่มีสิทธิ์อัปเดต การดำเนินงานของเราในปัจจุบันยังไม่สมบูรณ์แบบและบางครั้งข้อมูลการผลิตจะต้องมีการแก้ไข (ยังไม่มี GUI สำหรับสิ่งนั้น)

แทนที่จะติดต่อ DBA และขอให้เขาแก้ไขข้อมูลนักพัฒนาจะใช้บัญชี SQL (ไม่ถูกต้อง) SQLLogin1(ที่มีสิทธิ์ในการปรับเปลี่ยนข้อมูล) และเชื่อมต่อกับ SQL Server Management Studio เพื่อแก้ไขข้อมูลเอง

DBA ไม่สามารถเปลี่ยนรหัสผ่านได้หากSQLLogin1ไม่มี Developer จะเห็นสตริงการเชื่อมต่อใหม่และรหัสผ่านใหม่เนื่องจากสตริงการเชื่อมต่อแอปพลิเคชันที่ใช้SQLLogin1นั้นดูแลโดยนักพัฒนา

คำถาม:

มีวิธีที่จะปฏิเสธการเข้าถึงการSQLLogin1เข้าสู่ระบบ SQL แต่ถ้ามันเชื่อมต่อผ่าน SSMS หรือไม่?

ในเวลาเดียวกันหากSQLLogin1เชื่อมต่อผ่าน.Net SqlClient Data Provider( program_nameในsys.dm_exec_sessions) จะต้องได้รับอนุญาตให้เข้าสู่ระบบ

วิธีนี้เราไม่ต้องการให้นักพัฒนาเชื่อมต่อผ่าน SSMS โดยใช้SQLLogin1ในขณะที่แอปพลิเคชันที่ใช้อยู่SQLLogin1จะยังคงสามารถเชื่อมต่อได้

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

ตัวอย่างเช่น:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

ROLLBACKภายในไกจะปฏิเสธการเชื่อมต่อ (มีการทำธุรกรรมโดยปริยายห่อเรียกร้องให้ทริกเกอร์เกี่ยวกับเหตุการณ์การเข้าสู่ระบบ)

ระวังเมื่อใช้ทริกเกอร์การเข้าสู่ระบบหากไม่ได้รหัสอย่างถูกต้องคุณจะปฏิเสธการเข้าสู่ระบบที่ควรจะเข้าสู่ระบบ (รวมถึงของคุณเอง!) ตรวจสอบให้แน่ใจว่าได้ทดสอบสภาพแวดล้อมการทดสอบ / dev ก่อน

โปรดทราบว่ารหัสนี้จะถูกเรียกใช้ก่อนที่จะสร้างเซสชันดังนั้นมุมมองของระบบที่ใช้รหัสเซสชัน (SPID) จะไม่มีการลงชื่อเข้าใช้ที่ตรวจสอบในปัจจุบันจนกว่าทริกเกอร์จะสิ้นสุดลงโดยไม่มีการย้อนกลับหรือล้มเหลวสูงพอ

ฉันคิดว่าไม่มีวิธีแก้ปัญหาที่เชื่อถือได้สำหรับปัญหาของคุณเนื่องจากApplication Nameสามารถแก้ไขparameterได้โดยผู้ใช้คนใดก็ตาม

นี่คือวิธีการเปลี่ยนภายในSSMS:

ในConnect to Database Objectกล่องโต้ตอบเลือกตัวเลือกเปิด Additional Connection Parametersและเลือกชื่อใด ๆ สำหรับApplication Nameสิ่งนี้:

ตอนนี้sys.dm_exec_sessionsDMV และ Program_name () จะแสดงสิ่งที่คุณผ่านในสตริงการเชื่อมต่อของคุณในApplication Nameพารามิเตอร์:

คุณไม่สามารถตัดลูกค้าเฉพาะรายดังกล่าวแล้วโดยละเอียดในคำตอบอื่น ๆ

ทางออกคือการลบสิทธิ์การเข้าถึงระบบการผลิตออกจากบัญชีของนักพัฒนา

การเปลี่ยนแปลงใด ๆ จะต้องทำสคริปต์และ dba จะเรียกใช้สคริปต์

การปรับใช้จะดำเนินการโดยดูแลระบบ; devs สร้างแพ็กเกจที่มอบให้กับใครบางคนที่มีสิทธิพิเศษที่เหมาะสมและ devs ไม่เคยเห็นการกำหนดค่าที่ใช้ในระบบการผลิต

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

1. ในแง่ที่เหมาะสมนี่เป็นปัญหากระบวนการ / นโยบาย / การจัดการ แม้ว่าจะมีใครรู้รหัสผ่านถ้าขัดต่อนโยบายของ บริษัท สำหรับทุกคนยกเว้น DBA เพื่อเชื่อมต่อกับการผลิต (ดีคุณอาจมีทีมวิศวกรรม Release และ / หรือผู้ดูแลระบบ sys เป็นต้น) และมีบทลงโทษสำหรับการละเมิดกฎ จากนั้นควรจะเพียงพอ (สมมติว่ามีการบังคับใช้กฎดังกล่าว)

2. การพยายามป้องกันไม่ให้แอปพลิเคชันบางตัวไม่สามารถเชื่อมต่อได้ ดังที่แสดงให้เห็นถึงการติดเชื้อในตับมันค่อนข้างง่ายที่จะเปลี่ยน "ชื่อโปรแกรม" แต่แม้ว่านักพัฒนาซอฟต์แวร์จะไม่สามารถเข้าใจได้ แต่ก็มีโปรแกรมอื่นมากมายที่สามารถเชื่อมต่อกับ SQL Server ได้ คนส่วนใหญ่จะมีการเข้าถึงsqlcmd.exeและแม้กระทั่งเลิกOsql.exe นักพัฒนาสามารถเชื่อมต่อจากภายใน Visual Studio และพวกเขาสามารถสร้างแอพของตัวเองเพื่อเชื่อมต่อผ่าน ". ​​Net SqlClient Data Provider" โอ้และตอนนี้เรายังมี Azure Data Studio มันมากเกินไป

3. ถึงกระนั้นสิ่งนี้อาจเป็นไปได้ถ้าเราเข้าใกล้มันจากทิศทางอื่น: แทนที่จะป้องกันแอปพลิเคชัน X จากการเชื่อมต่อจะอนุญาตให้แอปพลิเคชัน Y เชื่อมต่อได้อย่างไร แน่นอนว่าเราเข้าสู่ "ชื่อโปรแกรม" อีกครั้งและแม้กระทั่ง "ชื่อโฮสต์" ก็สามารถปลอมแปลงได้ แต่ฉันค่อนข้างมั่นใจว่าที่อยู่ IP ของลูกค้าไม่สามารถปลอมแปลงได้ (อย่างน้อยไม่ผ่านคีย์เวิร์ดสตริงการเชื่อมต่อ) คุณรู้ที่อยู่ IP ของเซิร์ฟเวอร์แอพหรือสามารถค้นหาได้จากsys.dm_exec_connectionsDMV (ในclient_net_addressช่อง)

   เริ่มต้นด้วยLogon Trigger ที่แนะนำโดย EzLoเราสามารถแก้ไขตรรกะที่กำหนดว่าการเชื่อมต่อนั้นถูกต้องหรือไม่ต่อไปนี้:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;

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

ก่อนหน้านี้ฉันเคยทำงานให้กับ บริษัท ที่มีปัญหานี้กับผู้พัฒนารายหนึ่ง เขาถูกไล่ออก แต่เราก็ใช้ตารางที่มี LoginName และ AllowedMachine (Application Server) ผ่านทาง Trigger นี่เป็นการแก้ไขปัญหาของเรา หรืออาจเป็นเพราะการยิง