{"id":6540,"date":"2024-09-24T19:48:30","date_gmt":"2024-09-24T18:48:30","guid":{"rendered":"https:\/\/andreas-wolter.com\/?p=6540"},"modified":"2024-09-25T07:03:38","modified_gmt":"2024-09-25T06:03:38","slug":"extended-events-tracing-sql-compliance-principle-of-least-privilege-role-separation","status":"publish","type":"post","link":"https:\/\/andreas-wolter.com\/en\/extended-events-tracing-sql-compliance-principle-of-least-privilege-role-separation\/","title":{"rendered":"Using Extended Events for Tracing SQL Server and Azure SQL DB in compliance with Principle of Least Privilege &#8211; Example role separation"},"content":{"rendered":"\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-m0cxh8ps-5e62c9fd22249ec953de07439801bfc5\">\n#top .av-special-heading.av-m0cxh8ps-5e62c9fd22249ec953de07439801bfc5{\npadding-bottom:10px;\n}\nbody .av-special-heading.av-m0cxh8ps-5e62c9fd22249ec953de07439801bfc5 .av-special-heading-tag .heading-char{\nfont-size:25px;\n}\n.av-special-heading.av-m0cxh8ps-5e62c9fd22249ec953de07439801bfc5 .av-subheading{\nfont-size:15px;\n}\n<\/style>\n<div  class='av-special-heading av-m0cxh8ps-5e62c9fd22249ec953de07439801bfc5 av-special-heading-h3 blockquote modern-quote  avia-builder-el-0  el_before_av_textblock  avia-builder-el-first '><h3 class='av-special-heading-tag'  itemprop=\"headline\"  >Using Extended Events for Tracing SQL Server and Azure SQL DB in compliance with Principle of Least Privilege &#8211; Example role separation<\/h3><div class=\"special-heading-border\"><div class=\"special-heading-inner-border\"><\/div><\/div><\/div>\r\n\r\n<section  class='av_textblock_section av-m0cxgkjy-c935304b4106b45214698f40e83a9894 '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p>In this article, I want to outline how to use fine-grained permissions to lock down Extended Event Tracing for different roles and personas.<\/p>\n<h1>Background<\/h1>\n<p>When it comes to performance monitoring and troubleshooting, 3 major first-party tools are utilized regularly, either directly, or via other tools that build upon them:<\/p>\n<ul>\n<li>Windows Performance Monitor<\/li>\n<li>SQL Server dynamic management views (aka DMVs) (in conjunction with catalog views)<\/li>\n<li>Extended Events (<a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/extended-events\/extended-events?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Extended Events overview<\/a> ).<\/li>\n<li>Query store could be considered a fourth, but as it uses catalog views and is covered by the same permission as the DMVs (VIEW DATABASE PERFORMANCE STATE) one can argue they belong to the DMV approach.<\/li>\n<\/ul>\n<p>I have already blogged about <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/azure-sql-blog\/using-query-store-with-least-privileges-instead-of-db-owner-to\/ba-p\/775177\" target=\"_blank\" rel=\"noopener\">&#8220;Using Query Store with least privileges instead of db_owner to achieve Separation of Duties&#8221;<\/a>. The only thing to add would be that instead of VIEW DATABASE STATE, one can now use VIEW DATABASE <u>PERFORMANCE<\/u> STATE to query the query store views.<\/p>\n<p>With SQL Server 2022, the permissions for using Extended Events \u00a0(aka XEvents)have become granular as I had announced here: <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/sql-server-blog\/new-granular-permissions-for-sql-server-2022-and-azure-sql-to\/ba-p\/3607507\" target=\"_blank\" rel=\"noopener\">New granular permissions for SQL Server 2022 and Azure SQL to improve adherence with PoLP<\/a><\/p>\n<p>Here I will show practical examples of how to utilize XEvents under the <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/azure-sql-blog\/security-the-principle-of-least-privilege-polp\/ba-p\/2067390\" target=\"_blank\" rel=\"noopener\">Principle of Least Privilege<\/a>. The goal of the course is to grant only the minimally required sets of permissions for distinguished tasks or roles.<\/p>\n<p>Altogether we now have 18 permissions for XEvents, if we look at SQL Server and Azure SQL Database together. That is because in SQL Server XEvents exist on the server level, and in Azure SQL database on database level.<\/p>\n<p>The new permissions are hierarchically placed under ALTER but not further covering one another to allow a proper principle of privilege approach:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6547 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Server-300x179.jpg\" alt=\"XEvent Permissions on Server\" width=\"300\" height=\"179\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Server-300x179.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Server-705x422.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Server.jpg 766w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<p>If you compare the 9 permissions on server level with the database level permission, you will notice the only difference is the addition of the word \u201cDATABASE\u201d as part of the permission name:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6545 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Database-300x139.jpg\" alt=\"XEvent Permissions on Database\" width=\"300\" height=\"139\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Database-300x139.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Database-768x356.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Database-705x327.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Permissions_Database.jpg 971w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<p>Following are some examples of how these permissions can be split up for different roles.<br \/>\nI will use the server level permissions as example, but this concept can easily be translated to database level in a shared hosted Azure SQL Database environment for example.<\/p>\n<h1>Role 1) XEvent session administrators &#8211; manage all Extended Event sessions with full privileges<\/h1>\n<p>There will always be someone with higher privileges, who will<\/p>\n<ul>\n<li>Implement and XEvent sessions and let them run continuously<\/li>\n<li>Prepare XEvent sessions ready to be started by others only when the need comes up<\/li>\n<li>Prepare basic sessions as a starting point for others who may be allowed to add more events or targets<\/li>\n<li>And of course, they will have the power to stop and remove any sessions<\/li>\n<\/ul>\n<p>This role will have the <strong>ALTER ANY EVENT SESSION<\/strong> permission. (This permission is not new; it has existed since XEvents were introduced in SQL Server 2008 and was the only available permission until SQL Server 2022)<\/p>\n<h1>Role 2) XEvent support \u2013 start up provided sessions as needed<\/h1>\n<p>Another group of users can be those who have less destructive permissions and have merely the power to start any XEvent sessions that the XEvent session admins have prepared and view the collected data.<\/p>\n<p>The permission required is: ALTER ANY EVENT SESSION ENABLE<\/p>\n<p>In addition, to see the list of sessions (in T-SQL as well as in SSMS), they should also have the permission VIEW SERVER PERFORMANCE STATE.<\/p>\n<p>To ensure that members cannot accidentally stop other sessions that may be important to keep running, this role will not have permission to stop sessions ALTER ANY EVENT SESSION DISABLE.<br \/>\nThis is how these permissions are granted \u2013 to a server role instead of the logins directly as a best practice:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6555 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Support_Permissions-300x165.jpg\" alt=\"XEvent Support role Permissions\" width=\"300\" height=\"165\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Support_Permissions-300x165.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Support_Permissions.jpg 500w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<p>As a result, members of this role can list all defined sessions on the server, start any of them but not stop any, and they can also see the collected data.<\/p>\n<p>If viewing the collected data should not be included, then VIEW SERVER PERFORMANCE STATE would have to be omitted. But then these users would not be able to browse the system for which sessions have been defined. They would have to rely on using T-SQL and be given the names of sessions.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6557 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_TSQL_START_STOP-300x128.jpg\" alt=\"XEvent TSQL START STOP\" width=\"300\" height=\"128\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_TSQL_START_STOP-300x128.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_TSQL_START_STOP.jpg 502w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<h2>Using the XEvent Profiler sessions<\/h2>\n<p>Some of you may be using the built-in \u201cXEvent Profiler\u201d node, which is nothing else but a simple way to create 2 predefined session. Curiously, just to make things a bit more complicated, the sessions that will be created when you click on the names are different from what the name under the \u201cXEvent Profiler\u201d node says.<\/p>\n<p>\u201cStandard\u201d will create a session named \u201cQuickSessionStandard\u201d<\/p>\n<p>\u201cTSQL\u201d will create a session named \u201cQuickSessionTSQL\u201d<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6549 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler-300x300.jpg\" alt=\"XEvent Profiler session pointer to XEvent sessions on server\" width=\"300\" height=\"300\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler-300x300.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler-80x80.jpg 80w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler-36x36.jpg 36w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler-180x180.jpg 180w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler.jpg 320w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<p>Now as I said, clicking on these nodes will create sessions, they will not merely be started. And our XESupport will not have the CREATE-permission.<\/p>\n<p>If they try to use this functionality, this will fail with a permission error.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-6551 size-large\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror-1030x337.jpg\" alt=\"XEvent Profiler Permission error\" width=\"1030\" height=\"337\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror-1030x337.jpg 1030w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror-300x98.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror-768x251.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror-705x231.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Permissionerror.jpg 1232w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" \/><\/p>\n<p>But the solution is quite simple: someone with the necessary permissions, like our Admins, has to launch these \u201cquick sessions\u201d once and then stop them again. They will show up together with the regular sessions under the Management \u2013 Extended Events node, from where the support role can start them if needed \u2013 or using T-SQL, using the proper name.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-6553 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Start_Session-300x271.jpg\" alt=\"XEvent Profiler Start Session\" width=\"300\" height=\"271\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Start_Session-300x271.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_Profiler_Start_Session.jpg 320w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<blockquote><p><strong>\u201cBehind the scenes\u201d on permission naming<\/strong><\/p>\n<p>In case you are wondering about the permission names (ENABLE\/DISABLE) vs the command names (START\/STOP): When my team was deciding the proper permission names, we already foresaw that we should use the same permission name for other features that have a start\/stop logic.<\/p>\n<p>Other features in T-SQL that have the notion of being started\/stopped are Endpoints, Service Broker Queues, and Audits. For the sake of inconsistency :-D, ALTER QUEUE uses STATUS = ON | OFF and ALTER AUDIT uses the WITH (STATE = ON | OFF) syntax.<\/p>\n<p>(Auditing happens to be based on the internal architecture of Extended Events but for no particular reason, the syntax differs from Extended Events.)<\/p>\n<p>For the permission name, we wanted to ensure a common name that would make sense for all features, including future functionalities. That\u2019s why we decided to go with enable\/disable as terms, which then also were used for the Purview RBAC action verbs that were developed in parallel.<\/p>\n<p>This is the naming style in Purview RBAC: Microsoft.Sql\/Sqlservers\/ExtendedEventSessions\/State\/Enable<br \/>\n(more examples here: <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/azure-sql-blog\/use-microsoft-purview-to-provide-at-scale-access-to-performance\/ba-p\/3812839\" target=\"_blank\" rel=\"noopener\">Use Microsoft Purview to provide at-scale access to performance data in Azure SQL and SQL Server<\/a> )<\/p>\n<p>By the way: ALTER ENDPOINT uses STATE = STARTED | STOPPED | DISABLED. So, it will be interesting to see how that will be solved once in future extensions by RBAC or TSQL permissions even. Yes, I realized this too late. \ud83d\ude41<\/p><\/blockquote>\n<h1>Role 3) XEvent Admin helper \u2013 extend basic extended event sessions<\/h1>\n<p>Another role may be a group of people that is empowered to help adjust existing extended event sessions by adding more events and targets, but not removing existing parts of the sessions.<\/p>\n<p>This is possible because the ADD EVENT and ADD TARGET sub-commands of the ALTER EVENT SESSION-command are controlled by separate permissions from the DROP sub-commands.<\/p>\n<p>Adding and modifying predicates <u>for newly added events<\/u> falls under ALTER ANY EVENT SESSION ADD EVENT permission just as one would expect by the syntax. The same applies to adding Actions.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-6541 size-full\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_AdminHelper_Permissions.jpg\" alt=\"XEvent AdminHelper role Permissions\" width=\"800\" height=\"238\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_AdminHelper_Permissions.jpg 800w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_AdminHelper_Permissions-300x89.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_AdminHelper_Permissions-768x228.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_AdminHelper_Permissions-705x210.jpg 705w\" sizes=\"auto, (max-width: 800px) 100vw, 800px\" \/><\/p>\n<p>It is important to note that this also means that it is not possible to grant permission to change predicates for existing events. This is because behind the scenes, changing predicates and actions requires dropping and re-adding the same event with the new predicate\/action<\/p>\n<p>Like so:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-6543 size-full\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_ChangePredicate.jpg\" alt=\"XEventTSQL ChangePredicate\" width=\"575\" height=\"160\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_ChangePredicate.jpg 575w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2024\/09\/2024-09_XEvent_ChangePredicate-300x83.jpg 300w\" sizes=\"auto, (max-width: 575px) 100vw, 575px\" \/><\/p>\n<p>Therefore, the permission required for that would be ALTER ANY EVENT SESSION DROP EVENT.<\/p>\n<h1>Role 4) XEvent data reader \u2013 can view collected data<\/h1>\n<p>To view the collected data from XEvent sessions, there are 2 options besides the UI depending on the target type used (memory or file) (<a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/extended-events\/targets-for-extended-events-in-sql-server?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Targets for Extended Events<\/a>):<\/p>\n<ul>\n<li>query DMVs using XQuery for the targets that work in memory<\/li>\n<li>Query the system function <a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/system-functions\/sys-fn-xe-file-target-read-file-transact-sql?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">fn_xe_file_target_read_file<\/a> for the file target<\/li>\n<\/ul>\n<p>All of those are covered by the VIEW SERVER PERFORMANCE STATE-permission respectively the VIEW DATABASE PERFORMANCE STATE-permission.<\/p>\n<p>Solely reading XEvents data but no other DMVs is not possible. It is unlikely that this would increase security by much, given that XEvents can expose similar information as DMVs.<br \/>\nAlso, if we would have started going down that road, we would have had to create permissions for every sub-component or topic covered by the over 1000 DMVs and Catalog views that we have in SQL Server. An almost impossible task given that DMVs were never designed to strongly separate, and even if, the usefulness of this mega-task would have been super low after all since analyzing SQL Server usually spans multiple areas.<\/p>\n<p>If you have the requirement to allow a role to read data from XEVent targets and no other DMVs solely, then there is still the solution to use custom code:<br \/>\nThis solution essentially means that instead of directly granting direct access to the DMVs, one would create stored procedures that internally select the data from the XEvent targets.<br \/>\nThe user would be bound to the stored procedure&#8217;s logic and may expose via parameters. The permission to grant would be EXECUTE on the stored procedure (or better on the schema level if properly designed).<\/p>\n<p>This approach is depicted in my article about delegation here: <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/azure-sql-blog\/security-delegation-of-authority\/ba-p\/2214708\" target=\"_blank\" rel=\"noopener\">Security concept: Delegation of Authority<\/a>.<br \/>\nMore examples and explanations of the different options regarding authorization can be found in this article by Erland Sommarskog here: Packaging Permissions in Stored Procedures: <a href=\"http:\/\/www.sommarskog.se\/grantperm.html\" target=\"_blank\" rel=\"noopener\">http:\/\/www.sommarskog.se\/grantperm.html<\/a><\/p>\n<h1>Conclusion<\/h1>\n<p>9 distinct permissions instead of just one uber-permission allows for better role-separation and adhering to the Principle of Least Privilege when needed. I would not expect everyone to require this level of separation, but if you need it, this outlines some of the possibilities.<\/p>\n<h1>Limitation and feature-request to Microsoft<\/h1>\n<p>As I have pointed out before, there is one big gap in the Extended Events architecture: the concept of an owner:<\/p>\n<p>While there are a lot of opinions about the value of a MAC vs a DAC system, SQL Server is based on DAC and uses ownership to control access. Extended Events are one of the few objects that do not have an owner though. And the downside is clear when you look at these examples: all of these roles work on an all-or-nothing target. Either you have permission to add events to or drop targets from all event sessions, or none at all. There is no way to limit the space to something like \u201conly the XEvent sessions that were created by you\u201d. There is also no schema, where one could limit the permissions to a group of sessions within the same schema.<br \/>\nThe most flexible solution would of course be a label-based permission system, where one could say: roleX can edit all session labeled \u201cVendorApplicationZ\u201d and similar.<br \/>\nThis is why I would prefer SQL Server to support a true MAC-based authorization system.<\/p>\n<p>Dreams, right..? \ud83d\ude42<\/p>\n<p>Anyway, I hope this was informative.<\/p>\n<p>Happy securing<\/p>\n<p>Andreas<\/p>\n<\/div><\/section>\r\n\r\n<div  class='hr av-baku8u-c77559299fb7cb036a9bcb2d27e7c839 hr-default  avia-builder-el-2  el_after_av_textblock  el_before_av_one_full '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-8qrdby-716ba84fac604695b00357bfaeecd241\">\n#top .flex_column.av-8qrdby-716ba84fac604695b00357bfaeecd241{\nmargin-top:40px;\nmargin-bottom:40px;\n}\n.flex_column.av-8qrdby-716ba84fac604695b00357bfaeecd241{\nborder-radius:0px 0px 0px 0px;\npadding:0px 0px 0px 0px;\n}\n.responsive #top #wrap_all .flex_column.av-8qrdby-716ba84fac604695b00357bfaeecd241{\nmargin-top:40px;\nmargin-bottom:40px;\n}\n<\/style>\n<div  class='flex_column av-8qrdby-716ba84fac604695b00357bfaeecd241 av_one_full  avia-builder-el-3  el_after_av_hr  el_before_av_social_share  first flex_column_div av-zero-column-padding  '     ><section  class='av_textblock_section av-sfssu-f7aca6dd816d63048075328792dddaf6 '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><div><\/div>\n<div><\/div>\n<\/div><\/section><\/div>\r\n\r\n<div  class='av-social-sharing-box av-5n5vpa-c94cb34755a56dc3b3e18e46071a5152 av-social-sharing-box-default  avia-builder-el-5  el_after_av_one_full  el_before_av_hr  av-social-sharing-box-fullwidth'><div class=\"av-share-box\"><h5 class='av-share-link-description av-no-toc '>Eintrag teilen<\/h5><ul class=\"av-share-box-list noLightbox\"><li class='av-share-link av-social-link-facebook' ><a target=\"_blank\" aria-label=\"Share on Facebook\" href=\"https:\/\/www.facebook.com\/sharer.php?u=https:\/\/andreas-wolter.com\/en\/extended-events-tracing-sql-compliance-principle-of-least-privilege-role-separation\/&#038;t=Using%20Extended%20Events%20for%20Tracing%20SQL%20Server%20and%20Azure%20SQL%20DB%20in%20compliance%20with%20Principle%20of%20Least%20Privilege%20%E2%80%93%20Example%20role%20separation\" aria-hidden=\"false\" data-av_icon=\"\ue8f3\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Facebook\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Facebook<\/span><\/a><\/li><li class='av-share-link av-social-link-twitter' ><a target=\"_blank\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=Using%20Extended%20Events%20for%20Tracing%20SQL%20Server%20and%20Azure%20SQL%20DB%20in%20compliance%20with%20Principle%20of%20Least%20Privilege%20%E2%80%93%20Example%20role%20separation&#038;url=https:\/\/andreas-wolter.com\/en\/?p=6540\" aria-hidden=\"false\" data-av_icon=\"\ue8f1\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Twitter\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Twitter<\/span><\/a><\/li><li class='av-share-link av-social-link-linkedin' ><a target=\"_blank\" aria-label=\"Share on LinkedIn\" href=\"https:\/\/linkedin.com\/shareArticle?mini=true&#038;title=Using%20Extended%20Events%20for%20Tracing%20SQL%20Server%20and%20Azure%20SQL%20DB%20in%20compliance%20with%20Principle%20of%20Least%20Privilege%20%E2%80%93%20Example%20role%20separation&#038;url=https:\/\/andreas-wolter.com\/en\/extended-events-tracing-sql-compliance-principle-of-least-privilege-role-separation\/\" aria-hidden=\"false\" data-av_icon=\"\ue8fc\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on LinkedIn\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on LinkedIn<\/span><\/a><\/li><\/ul><\/div><\/div>\r\n\r\n\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-4ofg9q-c2108540b480aba02923089240a3a176\">\n#top .hr.hr-invisible.av-4ofg9q-c2108540b480aba02923089240a3a176{\nheight:50px;\n}\n<\/style>\n<div  class='hr av-4ofg9q-c2108540b480aba02923089240a3a176 hr-invisible  avia-builder-el-6  el_after_av_social_share  el_before_av_comments_list '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n<div  class='av-buildercomment av-284ftq-f5a1564cd6b8ffad6ce835e2d40de4b7  av-blog-meta-author-disabled av-blog-meta-html-info-disabled'><\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":4,"featured_media":6547,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,57,56],"tags":[27,363],"class_list":["post-6540","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-extended-events-en","category-security-en","category-tracing-monitoring-en","tag-security-en","tag-xevents"],"_links":{"self":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/comments?post=6540"}],"version-history":[{"count":5,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6540\/revisions"}],"predecessor-version":[{"id":6564,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6540\/revisions\/6564"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media\/6547"}],"wp:attachment":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media?parent=6540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/categories?post=6540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/tags?post=6540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}