Ngăn chặn nguồn dữ liệu được triển khai bên ngoài thư mục được chỉ định

7

Trước khi tôi tiếp tục và đặt một ràng buộc kiểm tra thực sự khủng khiếp trên bảng Danh mục, tôi muốn thu hút một số ý tưởng tốt hơn trước.

Tôi muốn đảm bảo rằng tất cả các nguồn dữ liệu được chia sẻ trên máy chủ báo cáo của chúng tôi được triển khai thành "/ Nguồn dữ liệu". Thỉnh thoảng, chúng tôi nhận được một triển khai nhầm sang một thư mục khác (đặc biệt nếu đó là báo cáo được nâng cấp từ SSRS 2000, không cho phép chỉ định vị trí triển khai nguồn dữ liệu khác).

Tôi có thể đặt một ràng buộc kiểm tra xấu xí vào Danh mục ( Type != 5 OR ParentID = 'GUID of /Data Sources directory'hoặc tương tự) nếu nó đi xuống, nhưng nếu có một lựa chọn tốt hơn, tôi thà sử dụng nó.

sql-server sql-server-2008 ssrs

— db2
nguồn

2

+1 Cá nhân tôi đã sử dụng các ràng buộc trong quá khứ và chúng dường như hoạt động, nhưng tôi rất muốn xem những gì người khác đã làm quá.

— OliverAsmus

4

Tại sao không thay đổi quyền để dân gian không thể triển khai nguồn dữ liệu cho bất kỳ thứ gì ngoài thư mục này?

Vì vậy, hãy xóa "Quản lý nguồn dữ liệu" khỏi tất cả các thư mục ngoại trừ /Data Sources. Điều này có thể được thực hiện ở cấp gốc và sau đó đặt quyền tùy chỉnh trên/Data Sources

Bạn có thể cần thiết lập vai trò tùy chỉnh cho việc này nếu bạn không thể thay đổi vai trò hiện có.

— gbn
nguồn

Yup, sử dụng Dịch vụ báo cáo được xây dựng trong quản lý bảo mật.

— DForck42

À ha, tôi luôn quên tôi có thể tùy chỉnh các vai trò, vì bạn làm điều đó từ SSMS và nó không ở ngay trước mặt tôi trong Trình quản lý báo cáo. Tôi đã loại bỏ "Quản lý nguồn dữ liệu" khỏi vai trò "Trình quản lý nội dung" và đặt nó trong vai trò "Trình quản lý nguồn dữ liệu" mới. Sau đó, tôi chỉ cấp vai trò đó tại thư mục nguồn dữ liệu. Tôi nghĩ rằng sẽ thực hiện thủ thuật ... ("Quản lý tài nguyên" không ngụ ý "Quản lý nguồn dữ liệu", phải không?)

— db2

@ db2: IIRC, "Tài nguyên" là hình ảnh và nội dung: không phải báo cáo và không phải nguồn dữ liệu và không phải thư mục (được đề cập rõ ràng)

— gbn

1

Tôi không nghĩ rằng MS thực sự đảm bảo bất cứ điều gì về cơ sở dữ liệu SSRS cơ bản, vì vậy bạn đang xâm nhập vào lãnh thổ không được hỗ trợ bằng cách thực sự hiểu rõ điều đó. Nói chung loại này là tốt nhất nên tránh trên các máy chủ sản xuất.

Bạn có thể truy vấn các nguồn dữ liệu và siêu dữ liệu máy chủ báo cáo khác theo chương trình thông qua API dịch vụ web được SSRS trưng ra. API sẽ cho phép bạn đi bộ trên các thư mục tìm kiếm các nguồn dữ liệu được chia sẻ ở những nơi mà chúng không phải là.

Săn bắn và báo cáo ngoại lệ có lẽ là cách tốt nhất để giải quyết vấn đề này, thay vì cố gắng ngăn chặn nó tại nguồn. Bạn cũng có thể truy vấn siêu dữ liệu báo cáo để tìm kiếm các báo cáo có tham chiếu đến các nguồn bên ngoài các khu vực được chỉ định. Điều này cho phép bạn giáo dục các tác giả.

MS cung cấp một tiện ích được gọi là rs.execho phép bạn viết các tập lệnh để thực hiện điều này trong VB.NET. Các phiên bản sau này cũng có thể hỗ trợ C # nhưng tôi chưa thực hiện điều này với bất kỳ thứ gì gần đây hơn SSRS 2005. Về cơ bản, nó đứng đầu và nối đuôi tập lệnh của bạn với một chút soạn thảo, biên dịch nó và sau đó thực thi nó.

Một số tài liệu về rs.exetiện ích và API dịch vụ web SSRS có thể được tìm thấy ở đây , đây và đây.

— Quan tâmOfTunbridgeWells
nguồn

1

Không phải là một ý tưởng tồi, nhưng tôi thích cách chủ động hơn là cách tiếp cận phản ứng. Mặc dù tôi thích ý tưởng tìm kiếm các báo cáo với các tham chiếu nguồn dữ liệu bị hỏng. Tôi sẽ phải xem xét thử điều đó - Tôi chỉ cần dọn dẹp một bó bằng tay.

— db2

@ db2 bạn có thể thiết lập một công việc và chạy nó trên cơ sở hàng đêm để chọn công việc này. Lưu ý rằng bạn đang thực thi một chính sách, không phải là bất biến với các phụ thuộc được mã hóa cứng.

— Mối quan tâmOfTunbridgeWells

1

Chỉ cần đưa ra một ý tưởng ngoài kia - trong môi trường của chúng tôi, các nhà phát triển báo cáo có quyền truy cập vào cơ sở dữ liệu nguồn nhưng người dùng báo cáo thì không. Tất cả các nguồn dữ liệu của chúng tôi được triển khai vào một thư mục và tài khoản dịch vụ được sử dụng để xác thực nguồn dữ liệu đó.

Các nhà phát triển báo cáo không biết mật khẩu tài khoản dịch vụ.

Vì vậy, với thiết lập này, nếu nhà phát triển báo cáo triển khai nguồn dữ liệu ở nơi khác, báo cáo sẽ không hoạt động cho người tiêu dùng báo cáo, chỉ các nhà phát triển khác. (Về mặt kỹ thuật, họ phải luôn sử dụng "không ghi đè nguồn dữ liệu" hoặc tất cả các báo cáo bị rối cho đến khi quản trị viên sửa đổi nguồn dữ liệu "mới" bằng tài khoản dịch vụ.)

Hi vọng điêu nay co ich!

— JHFB
nguồn

1

Điều đó thực sự rất gần với thiết lập của chúng tôi. Tất cả các nguồn dữ liệu sản xuất đều sử dụng tài khoản được xác định trước (thường là "Báo cáo dịch vụ", với các quyền chỉ đọc rất cụ thể), trong khi việc phát triển được thực hiện với xác thực Windows. Điều này bảo vệ bạn khỏi các báo cáo ngựa trojan đang được triển khai và sau đó được điều hành bởi ai đó có quyền quản trị. (Trượt CREATE LOGIN secret_admin ...vào truy vấn báo cáo, sau đó lừa ai đó bằng sysadmin để chạy nó ...)

— db2

Vì vậy, có gì nguy hiểm nếu một nguồn dữ liệu được triển khai đến sai địa điểm? Đó là, tại sao cần phải chủ động thay vì phản ứng? Hay đó chỉ là một thiên hướng nghiêng về "thực hành tốt nhất"? :)

— JHFB

Chủ yếu chỉ để giữ cho máy chủ báo cáo không trở thành một mớ hỗn độn thần thánh. Trong những năm qua, tôi đã nhận thấy entropy nặng nề nếu máy chủ của chúng tôi không được kiểm tra (đặc biệt là liên quan đến quyền của thư mục và báo cáo). Mối nguy hiểm duy nhất trong trường hợp này là giảm khả năng quản lý.

— db2