Security is always important to data folks and when a new feature like Always Encrypted comes along, it gets your attention. In this episode, we discuss this feature introduced in SQL Server 2016. We are joined by our guest Sam Nasr and he shares an overview and we find it may not cover all the scenarios you might think when you hear the name. Our discussion leads to scenarios in both on-premises and cloud solutions. Joined by Kevin Feasel and Eugene Meidinger, this episode will allow you to be a bit more prepared when you hear someone say all your problems will be solved with Always Encrypted.
“There’s no security that’s completely foolproof. There’s always some penetration holes, there’s always someone that needs to be the master of the keys.”
“You have Always Encrypted available to you and it just makes life a lot easier, and the ability to encrypt data without going through a lot of work.”
“It is not the be-all-end-all, it’s just yet one additional hurdle we can put between us and malicious hackers.”
“No one’s going to want to take on extra responsibility, typically it has to come from the top and they have to mandate it.”
Listen to Learn
01:24 Compañero Shout-Outs
01:54 SQL Trail
02:43 SQL Server in the News will start picking back up soon
03:10 Intro to the guest and topic
05:42 What exactly is the purpose of Always Encrypted?
08:30 Applications need access to the data
09:37 Why Always Encrypted, when there are algorithms out there that I can use?
12:49 The deterministic and randomized settings
15:25 Sam’s recommendation on when to use Always Encrypted
16:38 Always Encrypted is on by default in Azure?
17:38 Request for input from listeners who are managing keys on-premises
20:47 What if you’re using a third-party hardware security module?
21:27 A ‘gotcha’ with Always Encrypted and a compare/contrast of TDE and AE
24:48 How responsibilities with Always Encrypted should be shared
26:03 Last thoughts on Always Encrypted
28:04 SQL Family Questions
33:58 Closing Thoughts
Blog by Kasper on BI: Use Always Encrypted data with SSAS and Power BI
About Sam Nasr
Sam Nasr has been a software developer since 1995, focusing mostly on Microsoft technologies. He’s a Sr. Software Engineer with NIS Technologies where he consults and teaches clients about the latest .Net technologies. Sam has achieved multiple certifications from Microsoft (MCSA, MCAD, MCTS, MCT), and is the leader of the Cleveland C#/VB.Net User Group since 2003. In addition, he’s the leader of the .Net Study Group, an author for Visual Studio Magazine, and a Microsoft MVP since 2013. When not coding, Sam loves spending time with his family and friends or volunteering at his local church.
Carlos: Compañeros! Welcome to another edition of the SQL Data Partners Podcast, my name is Carlos L Chacon, your host. This is episode 147 and it is good to have you on the SQL Trail once again. Whether this is your first episode or you’ve been listening for quite some time, thanks for coming back. I do appreciate it and I hope that you find this episode informative. Today we’re talking about Always Encrypted. Sam Nasr, our guest, is a consultant out of Cleveland, Ohio, wanted to talk about some security-related features, lots that he presented, and I thought, well, let’s just pick one topic and so we’re going to focus on the Always Encrypted piece, here. This is interesting, and we’ll get into the details later, but again, a variety of encryption options and so this episode’s going to focus mostly on the Always Encrypted.
Before we get into that conversation, we do have a couple of Compañero Shout-Outs that I want to give, and I do apologize. I have been a little slack, lately, in getting in with LinkedIn, so you’ll forgive me for the delay in connecting with many of you. Torsten Strauss, Javier Gillin, Kenneth Neil, Ben Olster, Shejav L Najar, Raneth Ready, Christian Viejas, Abraham Halmarian and Alexander Lenares. So thanks, everyone, for connecting, it’s good to connect with you on social media.
As far as our SQL Trail event, October 10th through the 12th, in Richmond, Virginia, there is still some time to sign up. One of the things we haven’t talked too much about is the after-hours events. Those are starting to come together a little bit more formally, now. Wednesday, we’ll be starting at 2pm, some get-to-know-you, picking some sessions for Thursday, and then we will have dinner downtown Richmond, and then do a little sightseeing there in the city. The weather in October will be very nice. That should be a good time. Then on Thursday, a little bit more individual time, but if we want to do something as a group, we’ll actually be heading over to the Fine Arts Museum, which is right across the street from where we’re having our event, and we’ll be doing some touring. That museum is actually free and open to the public, so we’ll be taking a peek there, and doing some things as a group, there, so that should be exciting.
I don’t have any SQL Server in the News. It’s been a bit quiet lately, this summer. Although, I do expect as we get into conference season that the announcements will start picking back up. They haven’t announced a new version, yet, so I’m sure that probably means that they’re working on something a bit more complicated, and then that we’ll see when that comes out. But I do expect some more feature sets and whatnot to be unveiled as we get into conference season, so we’ll be waiting anxiously for those announcements.
Our show notes for today’s episode are going to be at sqldatapartners.com/alwaysencrypted or at sqldatapartners.com/147. With that, let’s go ahead and get into the conversation with Sam, Kevin, and Eugene.
Carlos: Sam, welcome to the program.
Sam: Thanks, Carlos, glad to be here.
Carlos: And of course, we are joined today by Kevin Feasel.
Carlos: And Eugene Meidinger.
Eugene: Hey, yes.
Carlos: It’s good to have you gentlemen again, today. So Sam, we do appreciate you taking a little time to chat with us. Our topic is security, but I’d like to focus in, at least in the beginning, on the specific security feature. This is something that is new, introduced in 2016 and then of course, has been expanded upon in the cloud services realm. Azure SQL Database, for example, this gets talked about quite a bit, and so we want to talk about Always Encrypted. This isn’t the first encryption option that Microsoft has made available in the database, so why don’t we maybe start off by talking about what Always Encrypted is? Because I feel like the name is slightly misleading, particularly when you think about, again, in the context of all the other encryption that’s out there.
Sam: Well, with Always Encrypted, essentially what it means is basically as the data is in transit, as it’s going from the database to the client, it’s encrypted there, and the assumption is that you also have it encrypted on the database, as well, like you mentioned, and it’s only when it gets to the client that there, it’s decrypted. So, you have the client-side encryption technology, and essentially what it does is, is takes the data that’s encrypted in the database, stays encrypted in transit, and that only when it gets to the client you have the driver that utilizes keys to decrypt the data.
Carlos: I think we’re on the same page, there, but I there’s one, I feel like one big caveat to that, and that is where I’m putting my encryption.
Sam: Details, Carlos, you know. Yeah, you can’t get hung up on these things. No, actually, it does require some set up and you do need access to the key for both the client. You certainly should not put it on the server, because essentially, you’re– I know, surprisingly, right? You should not be putting the key on the server, because essentially, if someone penetrates the server, and they have the key, then essentially, all the data’s exposed, there.
Carlos: So maybe I’m behind the times, here, guys, because I thought that Always Encrypted was column based. Is that changed?
Sam: No, that’s still the case.
Carlos: Okay, so because of that, because I am encrypting on a column, that’s a slightly different idea, at least in my mind, that’s a game changer, that when we think about TDE, for example, I turn the key on and then I can wipe my hands, my quote/unquote encryption is done, right? If the backup– in this sense– in this sense, hold on, in the sense of data at rest, somebody steals my backup, the whole thing is encrypted, right?
Kevin: In the sense that I checked a box for compliance reasons.
Carlos: Sure, sure sure, and I’m not saying– we can get into the minutiae of how valuable TDE is, and blah, blah, blah, but I feel like it is slightly different. It’s a different idea. When we think about encryption, generally we’re thinking about encrypting the whole database. For me, Always Encrypted, you have to be specific and say, “well, hey, gosh, we’re only encrypting by column.”
Kevin: Yeah, I think you have to think about it as “I’m trying to solve a different problem, here, with what I’m encrypting, why I’m encrypting it.” You are right that the purpose of TDE was basically to protect backups from being stolen and exploited. Always Encrypted is a different story. It’s compliance purpose is basically the DBAs have too much authority and have the ability to see too much stuff. Who guards the guardians? I’m not going to try the Latin version of that, because I’ll completely mess it up, but it’s a valid point. Who is in charge of making sure that the DBA, who is sysadmin, cannot see, modify, exploit this information, so it’s protecting from an insider-based attack, as opposed to the outsider-based attack that was more interesting back in the early HIPAA days.
Carlos: Sure. Who could penetrate this, kind of a thing, and this is almost like the Anthem issue. They get a hold of the database password, and that’s how they get access into the system, the DBA’s password, that’s how they get access.
Sam: But if you’re worried about DBA eventually getting access to the database, I mean, someone will eventually have access to it. There’s no security that’s completely foolproof. There’s always some penetration holes, there’s always someone that needs to be the master of the keys, if you will.
Kevin: True, true.
Carlos: Right, the difference is, at least you’re separating those. In theory, the database administrator could administer, or do what they need to do on the database without having access to that data. You’re separating the duties, in a sense. So, I thought that was interesting. Again, in my mind, we’re then kind of walking down the road of, “okay, with the amount of work that I would have to do to set up the encryption on lots of columns, I want to be very specific, here.” Maybe things like Social Security numbers, salaries, other sensitive data, but it’s not something that I’m going to be whitewashing the database with.
Carlos: Now, you talked about those keys that go back and forth, another challenge with this is that because the database is not doing the encrypting and decrypting, the applications have to have it. They’re the ones basically responsible for doing that encryption.
Sam: Exactly, and unfortunately right. So, it also means that for your client, they need to have a copy of the key on that machine, as well.
Eugene: Quick question, just out of curiosity. I know a lot of times when you’re dealing with Azure Services, they have an easy way to kind of roll your keys or regenerate keys, or that sort of thing. What’s the process for rolling keys if you do have a breach, or you need to change it, or whatever? Is there an easy way to handle that?
Sam: It’s a two-step process when you’re creating the key. First you essentially need to create a column master key definition, and then you create the column key encryption key, using the master key definition. Essentially, you could still maintain the master key definition and just create a new encryption key for that column.
Carlos: And then you’d have to extend that out to whatever applications that need to access the database, or at least that data, right?
Kevin: One of the big questions that I would ask, a leading question to start you out with. Why Always Encrypted? I mean, I can write my own applications that can encrypt data before it goes to the database, so what’s the purpose of this feature? What’s the pain that it’s trying to solve?
Sam: I think you just mentioned it right there. You never want to write your own encryption algorithms.
Kevin: No, I don’t want to write my own encryption algorithm, but I can use bcrypt or scrypt or something appropriately encrypt my data, using something that has been tried and tested, writing my own infrastructure, but not writing my own algorithm. I don’t have a PhD in cryptography.
Sam: Well, I mean, this is something that’s provided out of the box and it does auto-encryption when the data is written or read by the app. It obviously does require the access to the encryption keys, but again, it’s something that’s available within SQL Server 2016, all editions, so it’s available out of the box, essentially.
Carlos: Right, I think it gives you that ability to be able to implement without– and maybe, I don’t know if the easy button is the right word, but it gives you the ability to go forward with something, without having to know all of these other cyphers, if you will.
Sam: Exactly, and with minimal set up process, as well.
Kevin: Yeah, and I also see an advantage in that you can use Integration Services with Always Encryption and have that play nice, instead of trying to develop script tasks to try to decrypt your data. So, if that’s a big part of your corporate workflow, that can be a benefit.
Sam: Right, exactly.
Carlos: And it is worth pointing out that, again, once you start putting encryption on the data, all of the applications that touch the data, or that are going to use that data, are going to need those keys. So, you think about reporting or Integration Services, or data warehouse components, things like that. And again, that’s where you want to be very, very considerate as you think about which columns you’re going to encrypt and then the why. Because you’re going to have all of these downstream requirements, as a result.
Sam: Yeah, very true.
Carlos: While you get out of the box the ability to encrypt that stuff, you also need the applications to be able to read and write there, and at least in the .net world, you have to have 4.6 framework? Do you know, are there other limitations from an application side that might cause some heartburn for those trying to implement Always Encrypted?
Sam: Not necessarily heartburn, I mean it’d work pretty well, using the .net driver, but it does have some catches. Unfortunately, you can query the data, but you cannot use it without the encryption key. You can use similar brute force attacks and try to guess what the values are, and if you’re within range of that value, it will result in that record, back in the results set. Granted, it will be encrypted, and you can’t read it, but again, it will allow you to query that data.
Carlos: So, from SQL Server Management Studio, I SELECT * on encrypted information, I’m going to see something. It’ll be all hashes, but I’ll get a result set.
Carlos: I’m curious, what, if anything, have you done with the encryption setting? I know that there are these two settings, deterministic and randomized. Any pointers or thoughts around when I should use which one?
Kevin: Yeah, so deterministic, the way that it works is that every time you encrypt, say, the string ‘Bob’, it’s going to give you the same binary blob, so you’re able to store it. Randomized, by contrast, is going to introduce a nonce, so that ‘Bob’ gets encrypted to one binary blob the first time, to a different blob the second time, to a different, the third. The trade-offs, here. First trade-off is randomized is by far more secure. You can think of frequency-based attacks that will potentially come about with deterministic, where I can look for the same binary blobs and know that they represent the same thing, and if I have some concept of distribution of that thing, I can gain information about details on it.
Carlos: Right, so you get a GROUP BY and the ones that are used the most frequently are at the top, then?
Kevin: Yeah, so GROUP BY and filtering are only available, if I remember right, on the deterministic version, so the non-deterministic version, it’s basically just data that’s there. You’re not going to be able to do as much work with those columns. My personal bias is I don’t care. If I’m encrypting that thing, it’s probably something that I don’t want people to be sending me in decrypted versions of in order to filter. It’s probably something I don’t want to process, to work with, to try to do anything with, except hold it in the database, return it to the thing that cares about it. Otherwise, to me, it’s like a package that’s going through UPS or the postal service. Things in here, and I’m going to stamp that it’s in there. You want it back, here’s your package. It’s delivered to you. I stamped it, you got it. I don’t care what’s in it. I’m not going to try to process it. It’s all yours. Or maybe like a self-storage place in a skeevy part of town. Maybe that’s a better analogy for this.
Carlos: Yeah, I do know that deterministic, at least from a– when we think about tuning or looking at queries and whatnot, deterministic is a little easier to work with. Again, if you have to then balance your security requirement, verses your, “hey, how much do I need to work with this data” requirement. And that might be a factor in choosing which setting you decide to use. So, okay, so then I guess I’m curious, Sam, under what scenarios would you recommend someone use Always Encrypted?
Sam: Well, obviously protecting sensitive data, that’s a no-brainer, essentially. Obviously if you’re using the .net, the driver, then everything falls into place together, because it’s all Microsoft-based. So, you have Always Encrypted available to you and it just makes life a lot easier, and the ability to encrypt data without going through a lot of work. It’s very little overhead, creating the keys. The thing to remember, though, is the key managements. And of it, as far as the security in Always Encrypted, it’s available in all editions of SQL Server 2016 and later. So widely available for anyone to use, low hanging fruit, in my opinion.
Eugene: Something interesting, and we’ll put the link in the show notes, but Kasper Young has a blog post from about a year ago about how you can use Always Encrypted with SSAS and PowerBI, which is something interesting to know, because PowerBI likes to yell at you whenever you try to connect anything that doesn’t have encryption on of some sort, and SQL Server, by default, is just shooting stuff plain text over the wire.
Carlos: Interesting, okay yeah, I did know that PowerBI could connect to it, but you needed a special driver, there was a special setup there. So, in Azure, they talk about Always Encrypted being on by default. Does that mean that they’re creating a key for you, or what are we really talking about? Do we know, from an Azure perspective? As I was reviewing for this episode, I thought, oh, they made a big deal about Always Encrypted in Azure, but then when I remembered or realized, “oh hey, it’s only column-based, then what am really getting in Azure?”
Kevin: Well, you still get the same benefits here, where, all right, you have an Azure SQL Database, when they say Always Encrypted is on, that means I can go right click on the table and say, “hey, encrypt these columns for me, please.”
Carlos: Gotcha, so you have the option to enable that?
Carlos: It’s not that anything is encrypted by default?
Eugene: It looks like it’s not like a light switch like TDE or anything like that. It’s just that the infrastructure’s there, so it’s easy to get rolling.
Kevin: Right, yes, it’ll generate the keys for you. It’ll handle the key management for you so that you can take those keys and dump them off someplace secure.
Carlos: Yeah, there you go. Should we talk about key management for a second? On-premises, in Azure, I know Eugene you mentioned that they do have some services available for you to help manage those keys.
Eugene: Right, Key Vault, I think, does that for you.
Carlos: Yeah, yeah, exactly, like Key Vault and stuff. So, what are you guys using on-premises?
Kevin: I have no idea. I don’t manage keys, I got people who do that for me.
Eugene: Kevin Feasel, manager of two.
Kevin: Hey, hey, more than two.
Eugene: Oh yeah?
Kevin: Three is more than two.
Eugene: Yep, the math checks out.
Carlos: So, what about you, Sam, you gonna jump in, there?
Sam: Yeah, I was going to say, I guess I fall in the same category as Kevin. Being a consultant, you pretty much lead a client to water, but only they can drink, so you make the recommendation that it should be used, and how it will be managed. Unfortunately, not many of them jump on it unless they get bit. Just a sad reality, unfortunately.
Carlos: I would agree. I think some of the drawbacks of the encryption offering prevent or limit people from actually implementing, but this does sound like a potential podcast discussion. So compañeros, for any of you out there that are actually using keys on-premises, I would love to chat with you about how you’re managing some of those keys. Some of the things that have worked, some of the challenges you’ve had. It can be just between us, if you’ve lost a key before. I guess I can say that I’m sure we’ve all experienced that, to some extent. I think about SSRS or the catalog, as an example. I’m sure that those are probably more commonly lost keys than folks are willing to admit to. But I feel like that’s something that should change, eventually, is us being a little bit more aware about how our keys are managed. I guess if we’re not responsible for it being available, then yeah, I can see how that would fall down the priority list. Still something I’d like to chat about. If somebody’s out there and wants to come on the program and talk about it, I would be very interested.
Kevin: There are a number of third party solutions that will help you out along those lines. I’m just not that familiar with any of them because, again, that’s something that a system’s administrations and network administrations folks tend to do more than the DBAs or the database developers.
Carlos: Right, right. But it’s interesting, because those keys have to get created in the database, so that’s where I feel like the handoff needs to be pretty good, needs to be working there. Admittedly, it has not been a great experience for me, up unto this point. It’s, I’m saving a key, gosh, do I really say this out loud, in the backup folders, and that’s where I’m putting it.
Kevin: That whole TDE solution’s sounding better and better.
Carlos: Yeah, so I would be interested to see how other people are doing that. So that may or may not make it into the episode.
Sam: You know, before disclosing that, you should have at least disguised your voice and said that it was an anonymous caller that joined and volunteered that information.
Carlos: There we go, yes.
Sam: Also, I wanted to mention, as far as the key management, I mentioned before that with the Always Encrypted, it’s available in all editions of SQL Server 2016 and later. The only catch is, though, if you’re using third party hardware security module or HSM, that will require the Enterprise edition.
Kevin: So what does a hardware security module get you, in this case?
Sam: What does it get you? It gets you the ability to store the keys off-site and using a third-party product.
Eugene: Oh, interesting.
Kevin: Which sounds suspiciously like the answer to the previous question.
Carlos: Yes. Yeah, that’s interesting.
Sam: I can neither deny nor confirm that statement.
Carlos: Again, another reason why I want to talk with somebody about how they’re starting their keys, because that it is interesting. Another gotcha we didn’t really talk about was that the tables that are using Always Encrypted require their own chelation, or their separate chelation, and that can give people a lot of heart burn. But it is there available to help separate some of those things, you at least need the key to be able to get to that data, if that’s a concern for you.
Carlos: Now, having said that, should we then break in or maybe compare and contrast? I know we’ve kind of already brought up TDE. What’s the difference between TDE and Always Encrypted?
Kevin: The difference between Transparent Data Encryption and Always Encrypted. You know, we’ve talked about this a little bit, here, but for me, the story comes back to what was the regulatory environment that necessitated creating this product? Transparent Data Encryption, around 2008, the big thing was trying to secure data at rest. HIPAA was just starting to get some teeth, but they weren’t pushing data in motion, because hey, it’s too computationally expensive, so let’s worry about data at rest. Transparent Data Encryption says “yeah, we can cover data at rest,” so when pages are written to disc, they get encrypted. When backups are taken of those pages, the backups therefore, are encrypted and that satisfies the regulatory requirement for protecting data at rest. I think it satisfies it in a less than satisfactory manner, and we can get into that if you really want to nerd out, but I’m going to let you finish, first. Always Encrypted, by contrast, regulatory environment, as you get closer to this 2016 era, is looking at insider threats. It’s looking at people who have the authority to do bad things, or people who are authorized to be able to do things that can turn out to be bad. Like the Anthem case, somebody gets somebody’s credentials, that person happens to be a system administrator owning the entire environment. Now I can go and retrieve data that is sensitive information, so the regulatory environment is moving, we’ve solved data at rest. We’ve solved data in motion by forcing us to sell certificates on everything, which actually is a pretty solid answer, as long as you’re using TLS and not SSL, but again, avoiding the nerd-out. Now we’re trying to solve the problem of people who have too much responsibility, or people who carry a risk to the organization and so trying to limit what these people can do. Don’t prevent them from doing their jobs. The database administrator needs to be able to access these tables, needs to be able to defragment indexes, to run CHECKDB, to handle data corruption issues, to back up and restore databases. You know, it has to be able to do all of these things, but the database administrator doesn’t need to know what the specific details are in that column. The database administrator doesn’t need to know the specifics of that sensitive information. Their job is to protect that information, keep it from getting lost, keep it from getting destroyed accidentally, destroying it when it needs to be destroyed, and by encrypting that data before it gets to the database administrator, you now prevent the DBA or a rouge account from being able to query this information and retrieve it in plain text.
Carlos: Who’s going to make the decision, you know, CIO says, “I went to a conference, I heard about Always Encrypted, we should do that in our database.” What is a practical share of responsibilities when we talk about implementing Always Encrypted?
Sam: Well, I think we talked about the key management. That also needs to be addressed, who’s going to be taking care of that. For identifying which columns need to be encrypted, I think that’s going to open up a can of worms as far as how many keys are we going to maintain and then in addition, you can easily have someone say, “well, I’m not going to do it, I’m not going to maintain it as the DBA,” so the order needs to come from the top. It has to be from more of a managerial or executive level in order for that to carry through. Like I said, you’d have to identify which columns are going to be encrypted and then going forward, the maintenance of the keys is the big issue, there.
Carlos: That was kind of my thinking, is that this is another example of a collaborative effort. I think if it’s just the development team or even just the DBA team, there could be problems. It’s going to take a cross-section of folks to get this done successfully and make sure that everyone’s happy with the result.
Sam: And they all have to be on the same page. If you have one just simply saying, “I can’t do it” or “I don’t have time”, then the whole thing falls apart.
Carlos: Yeah, it can be very challenging, yeah. Well, awesome. Okay, so last thoughts about Always Encrypted?
Sam: Use it, use it wisely, and just remember there are still some gotchas. It is not completely fool-proof. It is not the be-all-end-all, it’s just yet one additional hurdle we can put between us and malicious hackers.
Carlos: It’s only a 2016 plus feature, so relatively new, so not everyone’s going to be able to use it, go out today and use it. What percentage of your 2016 databases, because again, this is a database level option, are using Always Encrypted?
Sam: Of the clients that I have come across?
Sam: Not many, quite honestly.
Eugene: It’s a niche feature.
Carlos: It’s a niche feature, yeah.
Eugene: Maybe some people out there would disagree with me, but I feel like Microsoft has hit most of the low-hanging fruit when it comes to relational database systems, so every year they have to find more and more fractally niche features to try and sell more copies or convince people to upgrade. And I think Always Encrypted is one of those things where for the people who need it, it’s absolutely awesome, but for most people, you’re probably either going to consider maybe sticking to just application side, or this really isn’t an issue that you need to solve. You know, if you’re a mom and pop shop with one DBA, you’re already putting a lot of trust in that guy, anyway, there’s no point in trying to split that division of security.
Kevin: And for the record, I love almost every niche feature that has been introduced.
Eugene: That’s because you guys find a bug in every one and then cause a hot fix to come out. True or false?
Sam: I’d also like to add, on top of that comment, that with regards to Always Encrypted, again, it may be low-hanging fruit, it may be available on all editions of 2016, but no one’s going to implement it, in most cases, at least until they have their arm twisted. So, no one’s going to want to take on extra responsibility, typically it has to come from the top and they have to mandate it. Otherwise, people get lazy, they get pulled into other projects, so something like that could easily fall by the way-side.
Carlos: Right. Okay, should we go ahead and do SQL Family?
Carlos: So Sam, your all-time favorite movie?
Sam: Alright, so this might make me a little dated, but I have to tell the truth. I would say T2, Terminator 2.
Kevin: That’s a good one. That’s probably the best of the Terminator series.
Sam: Yeah, I agree. That and Matrix 1. They just have not been able to do a better job than Matrix 1, in my opinion, with all the sequels that followed.
Kevin: The original was embarrassing. The sequels were dreadful.
Carlos: Oh gosh, yeah, I think taking an original idea like that and trying to sequence or iterate on it is tough.
Eugene: Kevin, don’t tell him that it was based on Plato’s Cave.
Kevin: It was a really cool idea when you’re 17 and you see it for the first time, and then you go back and watch it later and, “wow, I had really bad taste.”
Kevin: Fortunately, I never liked the second or the third, so I’ve got that going for me.
Sam: I think the second and third, they just tried to overdo it way too much.
Carlos: City or place you’d most like to visit?
Sam: Anywhere in Australia. Specifically, Sydney. I’ve heard a lot of good things about it.
Eugene: Have you heard about the fauna?
Sam: I have not.
Kevin: Like, not literally everything tries to kill you, just most things.
Eugene: No, I believe that everything there actually tries to kill you in Australia.
Carlos: Oh boy. So, if any Australians want to come back and talk about that, I’ll patch you directly to Eugene. Okay, food that reminds you of your childhood?
Sam: Food that reminds me of my childhood? Well, being born and raised in Egypt until I was 9 years old, there’s probably a recipe that you guys have never heard of, but it includes eggs beaten with a little bit of parsley and some flour and the smell just radiates through the house and it was incredible. My mother used to make it for me for breakfast, so as soon as that smell hits me, it’s just immediate flashback to childhood.
Carlos: There you go, interesting. So, a little bit of flour so it’s like an omelet, but it’s not quite a cake?
Sam: Just a little bit of flour, about a teaspoon-full and then the parsley mixed in, and once that all that hits the heat, the smell just permeates, and I’m 9 years old, once again.
Carlos: There you go, interesting. So, is this something that you still regularly eat or from time to time?
Sam: Haven’t made it in a while, but now that you got my memory jogging, I just might make it soon.
Carlos: There you go, there you go. Now, how did you first get started in SQL Server?
Sam: I stumbled upon it. I was working for a company where like I said, I had always worked along development and at this one company, basically they had me babysitting a third-party product and part of that included troubleshooting issues, which involved me going back to the back-end database and looking things up. I used to work with Oracle quite a bit, beforehand, but once I started working with SQL Server, I loved it because everything was just very intuitive, and I could get the answers that I need without these humongous tool-sets. Everything just started coming together and I started liking it more and more and essentially just dove in and started learning more about it.
Carlos: Now, if you could change one thing about SQL Server, what would it be?
Sam: I don’t know if I would change one thing. I’d probably add more features, specifically security-related.
Carlos: Seems appropriate, given our topic.
Carlos: Anything specific?
Sam: I would like to see, and this may seem a little bit far-fetched, but if you recall the RSA key fobs, I would like to see if that can be incorporated within SQL Server where it could utilize sending a user, or a user would have an app on his machine that would generate the key and then you can connect, and it would all be, again, based within SQL Server.
Carlos: Gotcha, interesting, okay. Yeah, so kind of a changing key that you don’t have to– for your connection information. Interesting. Best piece of career advice you have received?
Sam: This was something that I had arrived at, as opposed to being told, but I would say, “if you don’t find yourself moving forward in your career, change directions quickly.” Don’t put too much faith in management promising things that will come about, but start carving out your own path and make sure that you’re always moving ahead.
Carlos: There you go. I feel like I need to give a little shout-out here, to Eugene, having said all of that, who took a big leap in his life, here, and is going full-time to Pluralsight courses, that’s exciting for Eugene.
Sam: Should we give him a golf clap?
Eugene: I will accept a golf clap.
Kevin: Go watch his videos and give him a dollar.
Eugene: Yeah, I get like two dollars. You can either pay me and consider that a Starbucks coffee, or help pay my health insurance, whatever you prefer. I’m looking forward to never having to look at VB6 code ever again.
Sam: Seriously, though, congratulations, Eugene.
Eugene: Thank you.
Sam: That’s a big move.
Carlos: Our last question for you today, Sam. If you could have one superhero power what would it be and why do you want it?
Sam: Okay, so this may sound a little bit cheesy, and I was actually arguing with one of my relatives a while ago about this. I don’t know if you guys ever heard of Rubber Man as one of the superheroes.
Kevin: I have.
Sam: Have you?
Carlos: Is that the same like on DC, so like the Flash, where there was like he went to one of the other planets, like the Earth 7 or whatever and the guy kind of like Elastic Man, is that the same thing, or no?
Sam: No, I do remember the name, specifically Rubber Man. Haven’t seen him since, but I do remember that one. And as I get older in years, and the laziness kicks in, just to have the ability that I can reach across the room and grab whatever I want without getting up. That is just very tempting for me. So yeah, I would say Rubber Man, for sure.
Kevin: Was it Rubberband Man?
Sam: No, I think it was just Rubber Man. I could be wrong, it has been a while.
Carlos: Well, Sam, thanks so much for being on the program today. We have appreciated it.
Sam: Thank you, Carlos, it’s been a pleasure, and thanks to Kevin and Eugene, I appreciate your help, guys.
Eugene: Yeah, definitely.
Kevin: Thank you. Oh hey, Rubber Man on Earth Two, Enemy of Robot Man.
Sam: See, thanks for backing me up.
Kevin: Yeah, I thought I remembered the name and I had to go look it up, but yeah.
Carlos: There we go. Well, awesome. Thanks again, and the conversation’s been great.
Sam: Thanks, guys.
Carlos: I want to echo a comment that I think Eugene made in that the relational database is there, that technology is now very mature, and so we’re starting to get into more and more niche features. Encryption and security, I wouldn’t call it a niche feature, necessarily, but it is one where you have lots of different scenarios or problems that you could be attacking, and I think the Always Encrypted helps with just that. You have to really understand the problems that you’re trying to solve and then in this case, because it’s column-based, how you’re going to go after that. Again, just like anything else that they start announcing, you have to understand if it’s going to solve the problem or the pain-point that you’re having. I think as we get further and further along, we mentioned at the top of the show there hadn’t been a lot of new announcements for SQL Server over the summer, but I think as they continue to come out with more and more of these, they’re going to solve problems for very specific people, and not everyone will be using them. We’ll be interested to see how this continues to develop and grow, but obviously we know that security is a big issue. So thanks again, Sam, for coming on and talking with us. That’s going to do it for today’s episode, compañeros. Again, we appreciate you tuning in. As always, if you have topics or thoughts that you think we should be talking about on this program, let us know on social media. I can be reached on LinkedIn at Carlos L Chacon, and we’ll see you on the SQL Trail.