Azure SQL Security: Data Protection (Ep. 3) | Data Exposed Live

[Music] hi i'm anna hoffman and welcome to this episode of data exposed live we are super excited to have you all here today i'm hearing double sound one second it's like data exposed on repeat uh anyways i'm anna hoffman and welcome to this episode of data exposed live we're super excited to have you joining us today from wherever you are joining whether it's learntv twitch youtube uh twitter wherever you're joining in from today from today we'd love to hear from you so go ahead and put stuff in the chat we are looking at all of those we're going to be answering your questions throughout the session so please go ahead and take a look ask your questions make your comments we want to hear from you we want to keep this engaging now today we're going to be continuing the azure sql security series uh there were two episodes before this so if you miss those episodes later you can go back and catch up on them very exciting show today we're going to be talking about things like transparent data encryption always encrypted with secure enclaves and sql ledger so i'm excited to learn a lot and with all that aside i want to start bringing up our awesome guests so you can get to know them uh the first guest we have today is uh shoahan shum thanks so much for joining us today uh how's it going hey anna it's great to be here hello everyone joining us today for this session uh my name is shoham das gupta i'm a pm on the azure sql team and i focus on security and encryption at rest technologies like tde awesome and uh our next guest we have is let's see jason hey jason how's it going hey anna how are you it's great to be here great to have you jason can you tell us a little bit about what you do yeah you bet so i'm uh i work with shohom um i work specifically on the ledger feature of azure sql database uh prior to that i worked on azure blockchain service so i've been kind of in the blockchain space for a while and bringing that stuff to sql so excited to talk about it awesome great and last but definitely not least we have uh yaakov jakob thanks for joining us today uh can you tell us a little bit about what you do hi everybody um i'm the same team basically as jason and shoham security team i've worked over on a number of features over the years including always encrypted and ledger awesome so we have a great show today i'm going to take some of our guests out but you will be seeing them again and they're also going to be uh standing by to answer your questions um hi vishnu hi everyone else joining us from wherever you're joining us uh welcome again uh so show em before we get into the show uh for those that maybe have joined the series or haven't joined the series can you take us through a little bit about where we are in this journey of azure sql security absolutely so we started the azure sql security series um a few months back and we already had episode one and two so far so in episode one of the azure sql security series we went over the comprehensive security portfolio that azure sql offers to its customers and this includes the pillars that you see in front of you these are our fundamental security pillars for each of our security areas and each pillar contains security features that you would need to implement and all together we walked over how customers can use all of these features together to build a comprehensive security strategy for storing their data in the cloud after that in episode 2 we did a deep dive on the first pillar which is authentication and access management and this set of features was all about how do you make sure that you're authenticating users correctly into your database and also assigning them the right access privileges so they can can only see the data that they are entitled to so we did episode one which was a walkthrough of all the security pillars we did episode two which was the deep dive into authentication and access management and now we are in episode three where we talk all about the data protection security pillar awesome yeah i'm looking forward to getting right into it sure let's get right into it so data prediction uh security pillar deals with all of the security features that protect and uh make sure that your confidential and sensitive data in the cloud is protected now this has assumed a lot more significance in the recent years because organizations are embracing the cloud more and they are moving all of their data and assets to the cloud so obviously they are worried about the security of their data and is their data being protected in the cloud properly so data protection uh contains a list of features through which we make sure that your data is properly protected and encrypted while stored on azure sql and on the cloud now encryption is a fundamental aspect of data protection and at azure sql we make sure that your data is encrypted not at the state it is in now let's talk about the different states that your data can be in so encryption in transit is basically your data moving on the wire between your client application and your database and we make sure that any data that is in transit is always encrypted by dls encryption at rest basically refers to your data that is at rest on on the disks and it's in an inactive state and offline state this could be data in the form of database files backup files log files so we make sure that all of your data at rest is encrypted with a technology called tde and thirdly there is encryption in use which basically refers to data that is actively being used for instance for query processing and we have a feature called always encrypted through which we make sure that encryption and use can occur so let's go into one of the into each of these sections in more detail and let's start with encryption address sorry encryption and transit so like i mentioned in the last slide all of the data in transit between your client applications and your database server is always encrypted and we make sure that this is encrypted with transport layer security or tls which is an industry standard protocol for encrypting data in motion now tls encryption is enforced at all times for all connections so it's on by default and enforced all of the time and as a best practice we do recommend customers whenever you are specifying the connection strings and your client applications make sure that you turn the encrypted connection to on and do not trust the server certificate as a best practice there is also an option to enforce a minimum tls version in on on the server so this is a server property as you can see in the screenshot on the right hand side when you go to the azure portal or you can even do it through other means like api and powershell etc but um this is the screenshot basically shows you how you can go into the azure portal and select the minimum tls version which is a property at the server the database server level so we all we all know that um tls1.2 is currently the most secure version that azure sql supports so for instance if you were to enforce 1.2 as a minimum version on on the server then any of your clients that are accessing the server from a version lower than that would not be able to access the server anymore so you can basically prevent any clients that are using insecure versions of ssl dls from accessing your server in that way by setting a minimum tls version awesome so it seems like there are a few like pretty basic and standard things you can do for encryption and transit i just had a quick question if you set the minimum tls version does that apply like in and out of the server or is it one way yeah that's a great question so it applies both ways uh it applies for all traffic coming into the server and out of the server and what typically happens is once you have enforced a minimum pls version on the server then the first time a client application tries to connect to the server the minimum tls version is verified as part of the initial tls handshake between the server and the client so if your client for example does not support the minimum pls version that you have enforced then the server will deny that request right at the time of the initial handshake and if the user or the application user will receive an error saying that an invalid tls version is being used so yes it's imposed both ways and if your client doesn't support it then you will know as soon as you try to connect to the database server okay cool that's good to know thanks yep so moving on let's talk about encryption at rest so like i was mentioning data at rest can be uh offline and inactive data in the form of your database files your log files and and whatnot so this is data lying on the disk and not being actively used and there could be threats against this kind of data for instance a malicious user or attacker is able to access the physical disks at the data center and if it's not encrypted then they would be able to read that data and get access of your sensitive data so for this reason we have uh the technology called transparent data encryption or tde it's a very popular technology that lots of sql users already use and this basically protects against the threat of such malicious offline activity by encrypting the data that is at rest on the disk the encryption here is real time and that's where you have the transparent word in the transparent data encryption feature name so it's a real-time encryption and description of data and it's transparent to the application users so you don't need to apply any changes to the application but this is enabled by default so as soon as you create your sql database you get transparent data encryption enabled uh right from the start now encryption and transit that we spoke about before and encryption at rest are both table states for any cloud service provider these days and we recognize that encryption at rest is a very important part of compliance and regulatory requirements that organizations are required to achieve so organizations can basically meet some of their common compliance and regulatory requirements by enforcing encryption at rest and making sure that they don't turn it off once it's being enabled by default and along with other features that azure sql offers other security features encryption at rest enables uh defense and depth protection strategy so you think of encryption at rest as adding to the security layers that other security layers that i just typical already provides you can never say that encryption at rest is a is a full proof or one short method to scale your data but rather at azure sql be advised that customers should have a multi-tiered security approach and you can use other features starting from authentication authorization network security and encryption at rest to build a multi-tiered defense in depth approach as your best security strategy now let's talk about the different key management options that are available in dde so like i said ede is enabled by default so the first option which is also the default is microsoft managed keys so in this case microsoft will own the responsibility of managing your key generation key rotation and all of your different key lifecycle management operations so customers don't need to worry about the keys microsoft takes care of all of it and this is the simplest and easiest option uh that's also the default option that customers can use now there are other options for customers who are looking for more control of their of their key management and um need to basically have granular control over the different key operations so the second option that we provide is called bring your own key byok also known as customer managed key in which case the key management and storage is a shared responsibility between microsoft and the customer and by shared responsibility what i mean is the customer owns all of the key life cycle management operations starting from key generation key rotation providing access privileges to the key and revoking access privileges when needed so the customer owns all of the key operations and the key management but the key store is owned by microsoft and the key store used as actual keyword um so that's why i say it's a shared responsibility between microsoft and the customer in this case and we'll talk more about it in the next slide the third option that we provide is called hold your own key so in this one both the key store as well as the key operations are managed exclusively by the customer so the customer can basically retain control of their own key and they can also store the key in a hardware security module or hsn that they themselves own and is located in their own data center for instance now it's important to call out that the whole your own key or hyok feature is only available in infrastructure as a service or is which is basically sql server hosted on azure vm so if you have a sql server holster on azure vm you can effectively store the key in your own hsm and connect it to sql server by a technology called extensibility management or ekm so we do provide a bunch of key management operations it really depends on the level of security assurance and how stringent the customers security requirements are and they can choose what works best for them it's important to call out that if you choose to bring your own key or hold your empty option then you as the customer are responsible for making sure that access to the key is protected because in turn the key also protects access to your data so you basically get more options and more flexibility if you choose the second and the third option but it also brings more responsibility in making sure you are keeping your keys and your access privileges and what not secure uh lastly let's talk about double encryption at rest which is something that we have started offering recently so double encryption at rest refers to two independent layers of encryption to protect your data at rest and we achieve the two independent layers by firstly using tde as the first layer and then providing an optional second layer of infrastructure encryption infrastructure encryption is also known as volume encryption or disk encryption and customers can optionally turn it on to achieve two layers of encryption also known as double encryption at rest now you would think that why do i need two independent layers of list to eleven layers of encryption is td itself not enough while tde itself is a very good measure but typically two layers of encryption at rest help protect against a compromise or a key compromise scenario for a single layer of encryption and it provides higher security assurance in that way as an example you have enabled pde for your database and you are using the bring your own key option but supposing your key was compromised and a malicious user was somehow able to access your key so in such a scenario if you have the second optional layer of infrastructure encryption enabled then the attacker even though they have the tde key they just cannot decrypt your data because it is still being protected by the second layer of encryption so that's how two independent layers of encryption are better than one and um and this is a facility that we provide to customers who are interested and have higher security assurance needs okay let's move on and talk about talking in detail about the tde with customer managed case scenario using azure keyword so like i mentioned in the last slide this option essentially allows you to have more control over your key operations your key life cycle management and in turn ensuring who has access to your data and when it's also important to call out that the central key management that this enables allows you to do separation of duties in the management of your keys and data and by separation of duties what i mean is the responsibilities of your dba who's managing your database operations can be different from uh for example your key vault or your security admin who's managing your keyword and your keys so uh you basically get more control over your key management operations you are free to generate your key uh rotate your key as and when you need it provide access to your database or revoke access if if there is a breach or or when you need to so you have flexibility and assuming control of all of these things and like i mentioned the key store that i that we use is azure key vault which is a highly scalable and available cloud-based key store in azure azure keyboard offers multiple offerings for customers depending upon the level of security assurance that they need so you can use something as simple as software-backed keyboards going on to more stringent federal information processing standard or fips 142 validated level 2 and level 3 hardware security modules so these are specialized hsms or hardware security modules that protect your vault and customers have the option of using these more stringent security walls to store their keys so you can use any of azure keywords offerings we support all of them in azure sql and encryption keys can be generated inside of the keyboard if the customer needs to or if the customer already has a key that they are using uh for instance in an on-premise hsn then they can simply upload that key into azure key vault and start using it awesome this has been really useful i'd love show home if we could take a look at a demo absolutely right before the demo let me talk a bit more about uh the the separation of beauty scenario and then i'll dive right into them all so uh if you see the diagram when you write i was talking about how cmk or customer managed key with keyword enables separation of duties so you essentially have a dba here who's connected to your azure sql server and managing all of your data then you have a security admin who manages your azure keyboard and how do you now enable uh cmk for your sql server so the first thing that the dba needs to do is they need to enable what is called azure active directory identity for the server so once they enable that then the sql server will basically have what is called a system assigned managed identity or also known as an azure active directory at the identity and this allows the sql server to authenticate with the azure keyword so now that the identity has been enabled on the server the keyboard admin or the security admin can go and provision this server's identity the right amount of access on the azure keyboard and the access permissions that we need are get wrap key and unwrap key once this is done then the server will be able to read the key from the keyboard and use it for encrypt and decrypt operations it's also important that all if you have somebody like an auditor who comes in and wants to periodically audit the key operations and the key access on a regular basis they can use something called azure monitor to get a view of all of the recent audit logs and when a particular key might have been used for data access now let's move on to our demo so um in here we'll talk about how do you very easily enable customer managed keys on your server that currently has service managed keys enabled so let me shift to my azure portal screen so uh in here you see that i have a server called contoso server xo3 this is my database server i am on the transparent data encryption blade and right when it was created td was enabled by default and the service managed keys or the customer manage keys option was enabled so now i essentially need to transition this to uh customer managed key so for that let's move on to my key vault so i have a key vault here condo so keyboard demo and uh the first thing i need to do is assign my server's identity the right access on the keyword so i've already done that and what i did is i went to access policies in the keyboard i created a new access policy for my server and the key permissions that i have assigned are get rack key and android key so these permissions are sufficient in order for the database server to access uh the key that i have stored in my keyboard and use it to perform encrypt and decrypt operations on the database encryption key of the data of the database server now i'm not i don't have permissions to see the key here because just the server has access but when i had uploaded i already created a key on this keyboard and i have copied the key url because i need the key url to configure cmk on my server so let's go back to my server and configure cmk now so i select the customer manage key option and i add my key identifier on this is what i get from keyboard i could also choose to select a keyboard and a key or i could just choose to directly enter a key identifier so in this case i just entered the key identifier i hit save and what happens is behind the scenes sql servers checks that this server has the required amount of correct permissions on the keyboard and then it sends the data encryption key to the keyword to be encrypted the keyword encrypts the data encryption key and sends it back to be stored in the database so we got a success message here which means that customer managed key was successfully configured let's now use a slightly different mechanism to validate that this happens successfully so let's use powershell but you could as well use rest api or cli mechanisms to do this so what i'll do here is i'll first issue a command that gives me all of the encryption keys on this database server and as you can see on the top this is the encryption key that i just configured this is my uh keyword uri along with my key vault name and this key name that i configured so i know that this key was added successfully on the server it also also shows me the earlier key the service or the microsoft manage key that was there on the server now that the key has been added successfully i also need to verify that the encryption mode has successfully changed to cmk so for that let me issue the next command and in here i see that the encryption type is set to azure key vault uh the servers keyboard key name is set to the one that i needed and my keyboard is correctly configured so in this demo what we saw was how easy is it to move your server from a service managed key mode onto a custom managed keyboard by having your keys stored in keyword providing your server the right permissions on keyboard so that that's my demo and yeah hope that demo was useful yeah no definitely useful and very cool to see how you know there are different ways that we can configure it whether we're portal people or cli people and also how we can manage those different keys ourselves if that's something we want to do so sean i know we talked about encryption in transit and encryption at rest but i understand there's one more type of encryption and for that i'm going to bring up uh jacob um jakob you know maybe just to kick us off can you tell us or remind us again what the difference between uh trend encryption at rest in transit and in use is sure absolutely not so um data address is data that is stored on disk and database files and backup files right as shorthand explained and the data in transit is the data that is being exchanged on the wire over the y rather the network connection between the application and the database system right but there is one more state in the data lifecycle which is often ignored and forgotten and that is when the data is being used for query processing inside the database system right so consider this type of an attack where let's say a rogue malicious machine administrator operating system administrator it connects to the machine hosting the database scans the memory of the sql server process and exit creates um sensitive information right or even a simpler attack where a dpa connects to the database the dba can run an arbitrary query against any table right so the dba can run a select statement and get any data they want and even if you have tls or tdd enabled on the database these technologies would not protect such attacks right so that's why we need um encryption of data in use a protection mechanism that protects data that is being used in query processing now if you think about it if security was the only goal and data protection protecting data in use was the only goal that would be actually quite easy to achieve that right you could just dump encrypted sensitive information and in in into the database stored in the database and to you to meet your security requirements but then the functionality of the database system would be dramatically reduced basically database system will be unable to process any queries on this data that is encrypted so that's not what we want so what we want we actually want to achieve two goals that are conflicting and very hard to achieve together so we want to ensure that the data is protected these powerful adversaries high privilege unauthorized users cannot access the data but at the same time we want to ensure that the database system can reason about the data can perform computations on the data that is being protected right so we call this paradigm we call this vision confidential computing and an azure sql is unique in a way that it actually does have a technology that that addresses these that achieve these two conflicting goals and together and that technology is always encrypted so let me spend a couple of minutes explaining quickly um what always encrypted the it's this foundational architecture we introduced in 2015-16 and is and so this is the technology that again aims at protecting sensitive data and use from high-performance users both on-premises in the cloud and there are three important things i i want you all to to know about always encrypted is important that you you understand about always encrypted so uh element number one uh the the first fundamental concept is that always encrypted is a client-side encryption technology this is how we achieve the strong security guarantees of protecting data and use on them on the server side so basically the data gets encrypted decrypted on the client side and the data is never exposed in plain text and the keys cryptographic keys used to protect the data is never or never exposed in plain text inside a database environment so admins dbas operating system administrators cloud administrators even do not have cannot see the sensitive data and the clear or the keys in the database environment right the second important um thing i want to call out about always encrypted is encryption transparency right so the key component in this workflow is the client driver that performs dynamic translation between plaintext and ciphertext so what what it means is that it automatically and transparently encrypts any data that the application sends to the database the data that targets encrypted columns always encrypted by the way is a column level encryption scheme and it also transparently decrypts any data that comes from protected columns from columns that are encrypted so the data database application you as a developer you don't have to worry or know about which columns are encrypted which are not and how to encrypt decrypt data the client driver handles that for you transparently and finally um in this initial version of always encrypted release a few years ago we we made the first and fairly small let's be honest step towards delivering on this confidential computing vision right so we basically managed to support one confidential operation uh and that's equality comparison we achieved it through deterministic encryption and with that we can support queries like point lookup searches find me a person with a given social security number right or equality joins right um so that's that was this first initial step towards this confidential computing paradigm that we made a few years ago awesome this seems like pretty groundbreaking technology at least a few years ago and pretty advanced at how we figured out how to do the decrypting and encrypting without dbas having to necessarily know what's happening but like you said this only equality comparisons like maybe that's a bit limiting did we do we keep going exactly yes i agree it is limiting uh in fact many applications especially those that aim at or that handle uh personally identifiable information you know names addresses phone numbers you typically more need more than equality comparison to manipulate with the data you need pattern matching for example right and so this initial release of always encrypted this initial architecture of course didn't support such queries and the only option customers had was to move the data from the database to the client side and do these richer computations on the client side of course it's very expensive and inefficient from the first foreign point of view and and quite often to be honest infeasible if you have a large data set similarly you run into very similar problems when you let's say have a large table lots of data and you want to encrypt your column for the first time again in order to provide these strong security guarantees protection of data in use we cannot allow the database system to perform such cryptographic operations because that would mean that the sql server needs to have access to the keys and we need to protect and the keys from potentially malicious sql server environment right that's our assumption that's our thread model we don't trust the server which again means that in order to perform such operations you need to move the data from the server to the trusted machine outside of your database and perform such computations such operations they're very inefficient right so to address these problems uh we spent the last few years um researching solutions and we found a solution which leverages a technology called secure enclaves right so from the security point of view our goal remains the same right we want to protect sensitive data from high privileged users but we want to expand the functionality we want to be able to support more queries more in a broader ritual surface area on the data that is protected in this way right so for that as i said we're leveraging a new technology called secure enclaves the idea is that so what is a secure anchoring it's basically a a black box a piece of memory within a process like sql server that is basically inaccessible to anybody on the machine hosting that process even os kernel level administrators or dbas cannot see what's inside the enclave right um so therefore naturally it becomes a great candidate to be a trusted execution environment for processing sensitive information and that's exactly how we are using it so during query processing the query processor inside the database system delegates computations on encrypted columns to the enclave where the data can be safely decrypted and processed right and now we we can access plaintext data within that secure environment so we can support much richer queries and then in in the version of always encrypted which by the way is generally available in sql server 2019 and is currently in public preview azure sql database we managed to support pattern matching arranged queries and sorting and all of that with with indexing and a few more operations right so that's one very important benefit of securing the richer queries right but we also addressing this other problem um of encrypting data or performing cryptographic operations like key rotation at scale right you couldn't do that until now now we can support these operations inside the enclave in a secure way there is no need to move your data outside of the enclave and by the way uh we just heard from a customer who you know until recently needed to to to run this encryption process in the old way uh moving data out of the out of the database and it took over 20 hours and was still running and and with enclaves this can be done literally could be done within 30 minutes or so so dramatic improvement right of course the results will vary and depend on your setup schema and many other factors but um it's definitely way more efficient right um so um yeah so that's that's basically what uh always included with anchorages awesome this is really cool technology uh we did get a question that asked about uh performance and i think you kind of hinted towards the answer to that um i'd love if you could just briefly address you know how does encryption and use impact performance whether it's with always encrypted or with enclaves right great question so uh well i would offer kind of two alternative views um or perspectives on performance so one perspective kind of obvious is that well encryption always adds performance overhead right security is not free encryption is not free either so yeah if you see it this diagram yeah the data gets encrypted decrypted on the client side and it's also encrypted decrypted on the server side so yeah there will be some overheads we did some measurements and and we're gonna share some results in in the future uh probably some kind of a blog post but uh the the overheads were not substantial when we measured it against using popular benchmarks again i i don't have concrete numbers to share uh but yeah you you should be prepared there will be some overheads on the other hand you should always use always encrypted selectively to encrypt columns that contain only sensitive information not to don't encrypt all your columns in the database so you know if you encrypt just a few columns overall the end-to-end impact will be should be negligible to be honest now the other perspective i want to offer is that well if you think about it if you have a hard requirement to protect your sensitive data and use right what is your alternative to always encrypted the alternative is to encrypt the data dump it in the database and then you can do zero computations on that data right so in order to to do any computations in your into an application you could have to move the data out uh to the client side and around these computations they're very slow very inefficient so from that perspective always encrypted with enclaves actually provides performance improvements compared to these alternative approaches again if you have a hard requirement to never expose sensitive data to dbas to administrators including cloud administrators and microsoft operators right right no i think that's a great well-rounded answer and hopefully that helps uh our twitch viewer and some of our other viewers that were asking about performance um now i didn't mean to interrupt jaka but i'd love you to go deeper and take us through how this enclave attestation thing works yeah absolutely yeah so so uh you know um as we said uh one place bring these two important benefits richer computations in place encryption but it also uh generates some challenges right so one problem that you know enclaves introduce is if you again if we look at this diagram one more time is you know here the enclave it's supposed to trust as an extension of the client-side boundary it's like the agent behind enemy lines if you will right it's an entity that represents that trusted client within the untrusted sql server so an interesting question is how does the client actually know how can it be assured that this client this enclave is really trustworthy it hasn't been compromised it's not some kind of a simulator that is dumping your sensitive data you know in the internet or somewhere else right so we are solving this problem by introducing the auto station protocol and an attestation service so the idea is that before the client driver which is kind of the controller here for this entire workflow and it leverages the enclaves authorizes the use of the enclave for any computations on sensitive data it first verifies that this enclave is trustworthy is genuine and by the way we support different um enclave technologies in sql server using vbs enclaves so we in azure sql database we're using on a hardware archive so the other station workload verifies that you know the underlying enclave techno technology is is one of these two essentially um and the code running inside the enclave is what's supposed to be running there which is the library uh created by microsoft for always encrypted site in a very specific way with a specific signing key right so what that's what um what the other station um is about right awesome and i think you know you're going to talk about it next but i know that this is only available in a specific hardware today is that correct right exactly so so well this is particularly true in azure sql database where as i mentioned earlier very briefly we are using hardware enclave technology called inter software guard extensions or sgx which is not broadly available in our all our azure fleet right so which means that we need to we needed to give you an ability to basically control where your database is placed and to give you a way to express that you want to put your database around your database on hardware that is equipped with intel sgx and that's what we did we added basically a new option in the vcore model um in under sql hardware configuration um we call this option dc series when you enabled your app database is automatically automatically placed on a hardware equipped with intel sgx and always encrypted with anchors is available to you i want to mention just a couple of limitations um that you should be prepared to expect in the near future or midterm future number one is that this harvest is available in relatively um low performance machines with only eight cores so um that's uh how many cars can be associated to your database i want to emphasize that these are physical cores because hyper threatening is disabled on this machine so it's not apple to apple comparison with let's say gen 5 hardware configuration that most people use and currently we only support this hardware in seven regions and if you don't see your favorite region here on the screen uh let us know we might be able to accommodate um your request right and one other thing specific to sql db that i want to mention is that in azure sql database as an attestation solution we are using the new azure service called microsoft azure atta station and the nice thing about it compared to alternative that currently is the only option for sql server 2019 is that microsoft azure auto station is a platform as a service solution right so it's very easy to configure um you basically it's a policy driven technology so you define a policy for testing your enclaves which is evaluated before your client application uses the enclave for um computations on sensitive data and that policy basically i don't want to go into details now but you you basically state here that you trust very specific code to run inside the enclave and that's called a sql always encrypted library that implements cryptographic operations and you know rich computations um on sensitive data yeah gotcha cool this is this is awesome thanks so much jakob uh you know what would be awesome as if you have something to show us absolutely i'm prepared to show a quick demo here um so let's do that uh it's gonna be a quick demo demonstrating you know the value prop of the feature the main benefits so here for this demo i'm going to use a simple human resources hr application that allows me to you know manage or view my employee records i i can actually filter my records by employee salary by a portion of a social security number i can also sort my employee records by social security number or by salary it still says processing so we can we can give it a few seconds yeah that's what happens when you do the live demo your demo gets stalled when you do the slide presentations but okay it seems like it recovered so it still works and i can filter by all these things and sort by social security number and salary columns now this application stocks to a database another sql db um and here i'm connected to this database as a database administrator as a dba so i can query i can do whatever i want in this database i can run an arbitrary query however when i query a table that stores employee records i cannot see the the values in the social security number and salary columns in the clear because these two columns are protected are encrypted with always encrypted right so i cannot steal that data i can basically only see ciphertext i cannot see plain text so the data is protected now as a dba i have also configured an extended event session against this database which allows me to intercept extended events which basically um capture the queries that generate right so here um let's actually look at one of these queries okay let's see how these queries that the upsets to the database look like okay so i'm going to reformat this query a little bit so that we can more easily review how it looks like um so as you can see it's a simple select statement pulling some columns from the employees table but what i really want to call out here which is very unique and you cannot do that with any other um data encryption technology is the fact that this work class uh contains rich computations on columns which as you saw before were encrypted right so the ssn column is encrypted but we have a pattern matching comparison in this query against the ssn column we have a range comparison against the salary columns my columns are encrypted but the application can still issue rich queries against these encrypted columns right not only that um if we look at parameters which we need to tweak a little bit here so that we can actually see their values in a better way so here you can see that even query parameter values corresponding to encrypted columns like social security number min salary max salary which is somewhere else hidden behind the screen um these values are also encrypted right the client driver as we explained before encrypts these parameters before sending their values to the database so a malicious dba cannot even see uh the query uh filtering uh the filtering criteria that the op sense to the database that is protected as well so again the the the main takeaway from this demo is you can protect your data from powerful adversaries and at the same time you can continue running uh benefiting from rich query functionality uh the database system provides yeah this this is a really cool demo uh jakub uh i especially like like what you were saying you can prevent you can allow dbas to do their job without you know letting them see stuff or potentially have malicious uh intentions and see things that they shouldn't be able to see now this has been kind of a great encryption story but are there other tools or technologies in azure sql that we can take advantage of when it comes to kind of protecting or hiding sensitive data yeah absolutely there is there's one technology that i definitely want to quickly explain and talk about and that is dynamic data masking um so this is the technology which is very different from what we've talked about so far right so what we talked about so far where encryption technologies tls td always encrypted this is very different this is not an encryption technology there is a data obfuscation solution right so the idea is that we want to protect data from unauthorized application users it's very different than always encrypted that protects the data from system admins right and here the goal is to protect data again from unauthorized application users and what we do basically we mask the data on the fly when the data is being returned from the database to the users who are not supposed to see the data in the clear we mask this all this technology dynamically masks or obfuscate the data we provide um a number of masking functions for common um data elements or data types and like social security numbers phone numbers and so on and so you can leverage those existing functions or you can define your own masking function and what's important is that the solution is completely transparent to the application right so the application uh will continue to work when you apply this technology so i want to emphasize there's more of a development solution addressing developers who want to basically easily implement data masking for applications and this allows you to basically uh manage uh in one central place which is the database which applications and which users of these applications get to see sensitive information um a you know in in its original form versus the obfuscated format awesome thanks so much jakob this has been great and i feel like we as a team have a really great story about you know protecting data kind of at every stage of where it is or what who's trying to access it so it's been really useful so thanks so much uh next what we're gonna talk about is something really exciting really new uh and that is blockchain and sql so for that i'm gonna bring up uh jason uh and and maybe you can help demystify blockchain and sql and how these things go together absolutely thanks anna so far what jacob and shawn have been talking about has been encryption of data there's another element that's important when we think about protecting data and that is protecting it from tampering now blockchain has been you know all the rage the past few years and enterprises have been flocking to blockchain primarily because it provides an immutable record of data data that can't be tampered with and changed which is really helpful if you have a multi-party business process where some of the parties in the business process don't trust one another think of a supply chain as an example and so having that immutability that comes with blockchain is really attractive now one of the challenges that we've found is that many customers that want this level of digital trust if you will don't have the need for the decentralization of a blockchain and when i say decentralization what i'm talking about is a blockchain requires uh that every party that participates in it hosts infrastructure that infrastructure has to be connected it has to be governed the same and it's very challenging from an infrastructure and from a business process standpoint to set up but systems that are fundamentally centralized so think of systems that are in databases today um don't need to be decentralized to provide that level of tamper evidence and that's exactly what we're doing with azure sql database ledger is making data tamper evident through cryptography and it's very similar cryptographic elements that we use in blockchain today that we'll walk through now in addition to that we provide a historical record of all of the changes that have actually happened in the database so one of the benefits of azure sql database ledger is unlike a blockchain you can do updates and deletes to your database but still track it and detect that tampering if there's tamping that's occurred in that data and importantly uh being able to then provide cryptographic proof to other parties that may be consuming that data that could be other business parties or it could be auditors that data has not been tampered with is really powerful beauty here is that it's really just the sequel that you already know and love today that means that you don't have to change your applications there's no new t sql api to learn it's really just a function of sql that we've added that provides this level of digital trust without a complexity that a traditional blockchain may uh may afford so let's talk a little bit about what's actually happening here and what we're doing so we've implemented or introduced the concept of ledger tables inside of azure sql database now ledger tables are not a new table type they're a property of existing tables so you effectively can turn it on for your existing tables very easily but we'll first talk about the two types of ledger tables that we have and the first one are called updatable ledger tables so as i mentioned before being able to do updates and delete so how do we do that so let's assume for a second that i'm doing an update to an updatable ledger table changing a row what actually happens when the transaction comes into the system that the row that's been updated is actually that historical value is moved into a history table and the new value is in the updatable ledger table now those of you that are familiar with sql are saying it sounds a lot like temporal jason and it is it's really extending temporal functionality to a degree and that extension really comes in where we're adding additional uh metadata to the tables themselves to be able to track the lineage of those data changes so for example when that transaction comes in we associate a unique transaction id to it in the order of operations of which rows were changed in that transaction so that way you can actually go back after the fact and be able to see what's happened what transaction made what changes in the system now to make it easy to view we've actually created a ledger view what that does effectively is pulls together the updatable ledger table in the history table so you can actually get a chronicle here's the current value of this row here's the previous value of that row and so on now that's all data lineage information and just historical tracking let's talk about the cryptographic elements that are involved here so what i'm showing is a logical diagram of a we call the database ledger which is effectively a blockchain data structure so the data itself is cryptographically protected through the database database ledger using cryptography sha-256 sha-256 specifically as well as what's called a merkle tree so let's talk about what a merkle tree is otherwise known as a is a hash tree effectively what happens is every row in a particular transaction that comes into the system is hashed using sha-256 so hashing is a little bit of a can be a complex topic but effectively what happens is you have an input in this case it's the number of columns in the row the first column ordinal and so on runs it through the shaw256 algorithm which then produces a hash which is basically a 32 byte string of information um that is completely obfuscates what that data is now every row once it's hashed it's then we hash those rows together so as you can see here um the hash of row one and two are hashed together to create hash one two and three four and so on this is the merkle tree aspect of it creating what's called an apparent hash for those two rows this continues up until you get to the very top where you have effectively a root hash that represents all of the data elements in that merkle tree so in this particular case for the transaction all the rows that were hashed in that transaction are then represented by a single root hash now we call this uh we call this root hash or what we do with this root hash is we then use it for transaction hashing so let's go to the next step here and then talk about what happens there so each transaction itself using that previous route hash for the transaction again we go through the same process for all of the transactions that are happening within a given period of time and so that given period of time is what we call a block so during a during a 30-second interval all of the transactions that have occurred during that time are then hashed together up again creating a root hash for that particular time period of 30 seconds we call that particular root hash that represents those transactions in that time the database digest so the database digest itself represents the state of the database at that time that that particular block was created inside of the database itself okay and so these blocks at the bottom i'm just going to stop you so make sure i'm following correctly these blocks at the bottom this is kind of the block chain right because the block zero is linked to block one is this really like the same technology that blockchain is using this you're exactly right anna this is effectively what ethereum for example does today in other blockchains by creating each block the hash of that particular block is actually is is actually cryptographically hashed using the block of the previous hash so it chains them together which means you have to hack all of the blocks in order to be able to hack the database which is theoretically impossible to do cool thanks now this database digester that root hash for that block once we've created that we push it externally outside of azure sql database into a trusted storage location and the reason why it needs to go into a trusted storage location or i should say a tamper proof storage location is that those hashes are the root of the database trust at that particular point in time and what you use to then verify the data later which i'll talk about but let's talk about that trusted storage for a minute so trusted storage in this case we've built into azure sql database ledger to be able to connect directly to azure storage immutable blobs that ensures that those digest can't be tampered with but also a new service called azure confidential ledger which is a tamper-proof storage service so jacob talked briefly about always encrypted with secure enclaves and sql using that same enclave technology azure confidential ledger protects those digests um in in a in a very uh deep way effectively removing anybody from the trust boundary even microsoft from being able to get into those those digested forging those digests and that's important because if i want to then verify that my data has not been tampered or an external party like an auditor wants to verify that my data has not been tampered with what you then do is you issue a stored procedure that references the digest that are stored in trusted storage we then recalculate all of the hashes in the database real time to make sure or to determine if they match or don't match what was in the trusted storage if they don't match then we know a tampering event has occurred so what do i do at that point well at that point what i would do is use the forensics information the transaction tracking id the service principle etc to understand where the change is made in the database and then i can restore my database to an earlier point in time and be able to correct the data in the main database itself so that's updatable ledger tables let's talk about another table type which is or another table property of ledger tables called append only ledger tables it's effectively the same at the cryptographic level which you'll see up at the top the primary difference here is that we are blocking the ability to issue updates or deletes at the api layer so think of issuing a t sql statement to update a row that actually will fail inside of sql now this is important because this provides an extra level of security specifically a dba or privileged user would not be able to then tamper with the data by just issuing updates and deletes inside of the database so that's the uh the table structure itself inside of of azure sql database ledger let's talk a little bit about how do we actually enable and use this functionality so there's a couple of ways to enable or use ledger tables in in ledger the first is when you create a new sql database you'll notice in the create experience in the portal there's a new tab called security and you'll find things there such as address defender for sql and other properties but what you see here is there's a new area called ledger now this is not configured by default because there are some things that a user needs to do to configure this that requires some implicit decisions so if you click on this configure ledger uh button here you'll see a new um pane that gives you the opportunity to create um a ledger database effectively so what is a ledger database a ledger database means that all of the tables inside of this database when i create it will be automatically created as updatable ledger tables so you don't have to worry about whether a table is not protected or not now this is optional you don't need to do this here i'll show you in a couple of minutes how you can do this specifically through t sql but this is the easy button to ledgerize your database if you will ledgerize i like that the next setting you'll see is the digest storage so i talked about the trusted storage so as i mentioned supporting both azure storage and azure confidential ledger and again it's important to protect those digests so in the case of azure storage you'd want to configure an immutability policy to ensure that those digests are protected but we build this automatically now if you want you could uh not use the automatic digest storage you could pull those digest yourself by running a stored procedure and save them yourself but this is just again a way to make it a bit easier and to orchestrate the system together now once i have created my database i can go back in and to manage the experience there's a couple of things you'll notice here in the security tab there's a new ledger function here you'll see effectively the same user experience but one thing you'll notice is that this ledger database checkbox cannot be unchecked now this is by design this is a security consideration to ensure that you know the the azure tenant administrator couldn't go in uncheck that checkbox make changes to the database and then check it and nobody would be the wiser so this is a one-way option to ensure that it's protected also to note the i talked about azure storage azure confidential ledger is currently in preview it's free right now so great time to try it but at some point when it gets to ga it will be charged now note that azure sql database ledger however since it's a feature of azure sql database there are no additional charges it's just a core security fundamental that we've enabled um jason one quick question i have on that that previous slide uh you talked about enabling at the database level but then i can also create ledger tables if i have if i don't have it enabled at the database level can i still create ledger tables is there some sort of guidance there or i'm just confused no that's fine that's it's it's we try to give a lot of options which can be confusing in some cases but yeah so let's say that i to your point i want to create a database where i want to have a mix of ledger tables and non-ledger tables and yes you can absolutely do that so you could uncheck that during create and not do that you could still then configure the storage for digest and then what you would do is when you create a table you would specify this argument here ledger equals on in this case this will create this table as an updatable ledger table if i added the append only argument to it as well that would then make it an append only ledger table okay so in this example what i'm going to show is i'm just going to create a very simple schema of a bank account balance and i'm obviously turning ledger on here um one thing to note i should have mentioned as well is that you know a database can have a mix of updatable ledger tables append only ledger tables or no ledger tables at all it just depends on how you want to configure it yourself so let's go forward we've created this particular table schema here um so let's let's say that i'm going to now with this new table i'm going to add a new customer to this bank account and with an opening balance of 50 what you'll see here is that each transaction has that transaction id i mentioned before in this case nick jones with 50 deposit has a transaction id of 1104 okay now let's say that i want to issue a transaction that has uh it's going to add multiple parties to our multiple customers to this bank so john joe and mary with varying balances so you'll notice that not only is the transaction id the same for that because it's a single transaction but if you look over at the ledger start sequence number you can see the actual order of operations that that transaction happens so you know which happened first second third etc so this gives you again that ability to do the data lineage and forensics tracking of changes that have happened in the database now let's do an update since this is an updatable ledger table we're going to update nick's balance to 100 so what you'll see here is it's now 100 there's a new transaction id 1202 because that's a new transaction that issued that now the previous row the previous value of that row has been copied over to the history table as you can see there ledger transaction id 1104 now the way you would actually view this again would be through that ledger view i talked about and as you can see nick's update is showed as a delete of the previous row which was moved into the history table and then an insert of that 100 so you get again that chronicle view of the ledger over time by using the ledger view so let's talk about the blockchain level under the hood the way the blockchain is implemented is effectively in two new system tables the first is called database ledger transactions this lists here as you can see all of the transactions that have occurred inside of the database itself as well as the commit time of those transactions also capturing the principal name of the user that made those transactions so you know who did it and then of course the hashes that i explained earlier in the merkle trees that represent those particular transactions the next table is database ledger blocks so this effectively lists all of the blocks that have been created in the database and then since this is the first table i created in this database there's only a one block with a block id of zero that root hash or that database digest if you will of that block the size of the block which is four so there were four transactions and the previous block hash is null because this is the first block so if there's another block that showed up you would see that it would have the hash of the previous block there forming that blockchain got it so now that we've talked about setting up and tracking the data let's talk about that process of verification how do i verify the database so if you go back into the portal there's there's two ways to do it here one you can do it in the portal as you can see the manage experience there's this verified database command of the toolbar if i click that that will generate a t sql script that you would use to then run the verification so let's dive in and see what that would look like i could run that in query editor here or i can go over to like azure data studio or sql server management studio so this script effectively what it's doing is it's querying the locations where i've been storing my digest so i over time i could have used azure confidential ledger and then switched over to azure storage we coordinate all of that so you don't have to worry about moving your digests so we're going to query those locations and then we're going to run the verified database ledger from digest storage location stored procedure which references those digest and again recalculates those hashes and gives you the results so there's two things here in the results that are interesting the first is the digest locations so in this case what it's going to show is where those digests were and i'll show you that in a second the second obviously would show the result but was the verification successful or was there a tampering event in that digest locations you can see here that i've had four configured over time um a diff bunch of different digest locations but what's important to show here is which one's the currently configured one which is is current true in this case it's my azure confidential ledger and all the previous ones that show false were the ones that were previously configured now this is important because an advanced attacker could actually point to a different storage location with forged digests so inspecting this when you run your verification ensures that it's pulling the digest from the locations that you actually configured gotcha this is pretty cool it's also cool you can see a history of what's been used and we just tracked that for you exactly exactly so the core scenarios where we see ledger as being really helpful is number one just streamlining the audit process it's when i say the audit process that could be an internal audit such as for a line of business application for your internal organization it could be external audits we have external auditors come in being able to provide an audit or cryptographic proof that your data has not been tampered with is really powerful so we see it as just a core security fundamental technology where if you have any production data that you want to protect from tampering uh ledger can do that for you now we've also seen it as an alternative to blockchain-based solutions so again where ledger is really powerful is where you have again a centralized solution where other parties that may participate in your business process trust that central party but they want to verify um so they have the ability to then verify that so we've seen many customers who were going down the path of a blockchain where they really didn't need it turning to sql ledger as an alternative now in addition azure sql database ledger is a great addition to an existing blockchain and the reason being blockchain systems are notoriously difficult to query they're not designed as an oltp type system for that purpose so a typical pattern that has existed would be for customers to take their blockchain and take that blockchain data and stream it what they call off chain to a database but as soon as you do that you lose the immutability guarantees of the blockchain well with azure sql database ledger you can now maintain that integrity from the blockchain to the off chain data store and azure sql database so to give an example of the auditing process i'm going to go and turn it back over to jacob who's going to walk you through a really cool demo that extends upon the demo he showed earlier so jacob take it away sure thank you jason okay so let's actually resume where we stopped the previous demo right so um i'm locked still as a dba to the contessa hr database and i can query the employee tables actually um the dba i'm impersonating happens to be also an employee of the contoso company his name is jay adams right and we're looking at his employee record right here um so as we explained before when we talked about always encrypted jay who is a rogue dba in this scenario he cannot steal or exfiltrate sensitive information stored in ssn and salary columns because these columns are encrypted they are protected with always encrypted but so we we kind of covered on this attack vector however jay can try to tamper with the data right so always encrypted makes the tampering scenario is slightly more challenging for jay because he can also let's say jay wants to maliciously make to make an out unauthorized race update of his salary give himself a raise essentially and so how can he do that so since the salary column is encrypted he cannot just insert an arbitrary value there because he doesn't have access to the keys that would allow him to encrypt that value and insert the proper ciphertext in the salary column since the column is encrypted but he can try something else so let's assume that jay knows that katrin another employee at contesso catherine holds a high level position so jay makes an assumption that catherine likely makes more money than he does so he she has a higher salary so um an attack that jay is going to try is basically to replace his salary with catherine's salary so by executing this simple update statement right so now uh you know sometime later when this hr application refreshes it picks up a new js updated salary which happens to be the same salary now this application shows that in the clearing plaintext because it can decrypt it as we explained before uh so jay is happy and he's hoping uh for a nice paycheck in the next paying period however unfortunately for jay this employee tables was created as a ledger table which means that all the updates all the changes any user in triggers again against the table all these changes are preserved captured in a cryptographically protected ledger backed data structure so uh again unfortunately for jay a few weeks later um another user comes in and logs on to that system to that application that user is alice and she plays a role of an auditor so to begin her routine review of changes in the contest hr database alice starts with verifying the letter running the ledger verification to actually ensure that she can trust the data she's going to review subsequently so in the next step alice enters clicks on this employee ledger tab which basically pulls the data from the ledger view for the employees table and and that view as jason explained is a chronicle is a journal that captures the history of changes against um employee records and here um alice can uh easily not just find um the records indicating that first of all um jay's salary was updated uh increased and she can also see that it was jay who has made this change right and because the ledger uh data and the data and the ledger data structures have been have been has been cryptographically verified uh we know the data is genuine and it hasn't been tampered with it will be impossible in practice for jay to deny that he was the one who made this malicious change right now let's look at another example of an attack scenario uh in this example a malicious bad actor is not a dba but it's another um employee at contoso who is an hr um team member so her name is rachel and rachel uses um this hr application and rachel decides to you know let's say she's a close friend with francis and she wants to give francis enough unauthorized salary raise so for that she uses this hr application and goes here and changes the salary to a much higher number saves the results so now the same story with the auditor a few weeks later auditor comes and as usually the altitude shoot and would start with verifying the ledger integrity and then in she would review the um data in the ledger view for the employees table and now as before the auditor would notice the suspicious and very high percentage-wise increase of salary of one of the employees but now the challenge is that if we look here at the username column this column doesn't provide a lot of useful information this time right so basically it states that these changes were performed by the web application this is the uplink that the identity that we see in this column this is the identity the manage identity identity of the contoso hr application that is by the way deployed running in azure web apps right um so we cannot tell who actually was the application user who triggered those changes we only know that the changes were triggered through the application unfortunately for that attacker and rachel this application has been instrumented so that um any query any update uh sql query that users of these applications trigger against the database through their actions using the ui of this app are persisted or written to another table which its name is of the defense and it's also a ledger table in fact it's an append only letter table and it captures the query statement the name of the user and the time the query was issued and executed triggered by the application user so back to the um auditor story um right here um when the auditor next clicks on this audit event stop that pulls the data from the audit events table um the author the author will see will find uh the query statement uh that clearly updates the salary of one of the employees and the name of the user the application end user could trigger that change right so what i showed you in these two attack scenarios in these two attack examples um is that a letter basically uh helps ensure non-repudiation because the data is cryptographically verified as general and these attackers cannot be effective in denying they have made the change right so as jason said ladder in this case helps streamline the auditing process and makes this process fast and easy wow this is so powerful and very very interesting and it's cool how simple it is how it's all using t-sql i just have a few questions about you're watching the demo and then we have a few questions on learn tv i think we have a few extra minutes um so for the second piece with rachel uh we're using an append only ledger table um but rachel isn't blocked from doing the update we can just now audit that an update was made how does that work right so so not not exactly so there are two tables here uh let's clarify that right so there is an employees table and this is the main table that is a back backend of that you know olpp system this hr oltp application and which can issue insert update delete statements against the employee tables and all these changes are preserved right and and cryptographically protected and yes so rachel d malicious user can issue an update statement against the improv able to update somebody's salary there is nothing preventing stopping radio from doing that but all the changes you know these changes will be preserved however you know because there is this web application in the middle uh we know that the application has done these changes but we don't know which user now we also have another table and that table is an append only table that are the advanced table right so what we capture here is basically the result of instrumenting this web application which you know whenever you click on the edit button and then make a change let's say um in the web app you trigger the update statement and what the application does it sends there it inserts that update statement it adds a new record to the audit events table so we do not do not expect any other operations against this table other than inserts which is why it has been intentionally created as up and only table and you cannot so basically whatever you any statements and the queries you persist there uh cannot be cannot be even modified because there is no api for it right is an update and delete statements are blocked only inserts are allowed wow that's really cool it's cool so we're using a combination of technologies and strategies to make sure we can track everything uh but ledger tables make it really easy for us to do that basically yep that's the object awesome and then um one question that came through is uh you know this capability is pretty new which regions is sql ledger supported in today right uh so okay so today uh sql ledger um is in the process of being deployed to azure worldwide um currently as of today i believe and jason can correct me here and i think it's supported in a couple of regions uh jason can you chime in and remind me and tell all of us which regions we are supporting later in today as of now yes as of today and i just checked we are in west central us um and but we're rapidly rolling out so we expect to be in brazil south west europe north europe very soon so just keep your eyes peeled for that we'll we'll have updates in the documentation that show what region that's in but if you want to try today west central us is the place to give it a shot awesome okay that's great to know thanks jason for uh for hopping in there um also i just wanted to share with everyone watching and our presenters specifically we got we've gotten a lot of really positive comments through learn tv twitch twitter uh one comment we got is really amazing to see this new tech i was so excited to see it roll out um someone also said this ledger feature is my favorite from microsoft build uh so lots of excitement about uh ledger as well as the always encrypted and other other capabilities you all have shown to us today um so jakob as we look towards wrapping this segment uh is it can you just kind of take us through a summary of what we've done and also for people following the security series you know what's going to be next absolutely uh so in a previous episode we discussed authentication and access management and today we covered our data protection pillar we talked about encryption technologies um tls td always encrypted we talked about dynamic data masking for obfuscating data and making data inaccessible for um to unauthorized application users and we talked about ledger the the newest and and really exciting technology and we just uh roll out and build and so that's what we discussed today and we will continue our journey through all these and different security pillars we have three more to cover um so that's our plan for the next few months awesome um and let me just for folks following this series uh what i wanted to share is that there are lots of resources for you to learn more so if you check the description for this video you will be able to dive into all the topics you saw today which i recommend there are a bunch of really interesting documentation and even a new white paper on sql ledger so definitely want to check that out uh additionally if you're following this series or forgot that this is part of a series this is the third episode like jacob mentioned in this azure sql security series that we're doing if you missed the other two two episodes or you want to watch them again or revisit them they are time coded and located at that aka.ms url at the the top you can also find them on our youtube channel if you subscribe uh to our youtube channel at sheep at azure sql youtube um and just a sneak peek uh jaka mentioned these as well but this is our tentative calendar for when we're thinking about airing the next episodes in the series so you'll want to check back in august for the next episode on azure sql security uh now i'm just going to bring up uh the rest of our speakers today just as we close out you know i just want to thank you all so much for joining us i learned a lot i know this was a long jam-packed episode i think our viewers have learned a lot it's very clear in the the comments and uh some of the feedback we've been getting um so thank you so much to our speakers and to our viewers thanks so much for joining us um i know you know sometimes security is a heavy topic but you can tell there's a lot that we're doing and i think you know each of the speakers mentioned how you know security is really a big priority when it comes to protecting your data uh and in this case data protection um so thanks to our viewers uh if you like this video go ahead and give it a like subscribe to our youtube channel we stream live on learn tv every wednesdays at 9 00 and we hope to see you next time on data exposed you

Channel: Azure SQL

Views: 625

Keywords:

Id: XuoJwjOZPZw

Length: 89min 39sec (5379 seconds)

Published: Wed Jun 16 2021