Do you know who has access to what? This is the Identity at the Center podcast. If you're looking for identity and access management talk, you've come to the right place. And now on to the show. Welcome to yet another episode of the Identity at the Center podcast. Certainly been appreciating the likes and ratings we've been getting.
If you like what you hear, do us a favor, share the show with other like minded individuals And you can also e-mail us at questions at identity@thecenter.com. I am Jeff and that is Jim's voice you're about to hear. Jim. Hey, Jeff, survive the hurricane. It's by the hurricane. Well, so far anyway. I'm 100 miles inland and that helped. Yeah. So then I guess I'm a Hurricane survivor as well too, being up in the Chicago area. That's right.
Yeah. We're joined today by Morgan McNamara. She's one of our crack members of our engineering team here at Identity. Hello, Morgan. Hey, Jeff, How's it going? Good. Thanks for joining us today. Yeah, no problem. So Jeff, I want to clarify by being a crack member, that doesn't mean you smoke crack, right? They don't have. Well, you know, that's a personal question. I don't think that that's probably right for the podcast. I think as long as the work gets done, hey man, whatever.
Not that I'm condoning that behavior. There you go. So today is Thursday. Do you know what today is, Jim Morgan? Take a guess other than you know, podcast day. Thursday there's. It's an olasp day. It's not that. It is the opening night of the NFL. Bears, Packers. My Bears actually are looking good now. So there's a chance that we might actually beat the Packers on Thursday Night Football tonight's open season. I'm very excited about this. Now those teams have probably
played about 100 times. Yeah, and it's relatively even even though the Packers seem like they've been dominating the Bears for the last decade or so, the the actual overall record is relatively close, which is makes it one of the better rivalries. Yeah, cool. Morgan, do you have a team that you follow in the NFL? God, out of obligation, I have to say the Buffalo Bills. All right, on. Yeah. Go Bills. My dad is one of the Bills fans, so I get you on that one.
He's from Newfane and Rochester area, so So yeah, the Bills were his team. Okay. Yeah, that's like right next to me. I'm from Buffalo, so try your hardest bills. Jim, do you follow? The team Eagles. That's right, Eagles. Of course. Did you see that the Eagles offensive line did the ESPN Body Issue? No. Yeah. So if. If that's your thing, just not. Clear it's not. This is the first time in 25 years of NFL football that I'm not doing a fantasy Football League.
And I gotta tell you, I find it to be quite free. I'm actually going to be able to watch the games, enjoy them, rather than wonder, you know, how my running backs did or are, you know, having second thoughts around not starting one guy and him on the bench. So. Yeah, no, no. I stopped doing it about 10 years ago, and I feel the same way. It was like it's ruining the game for me.
And I did the same thing with fantasy baseball, where it's like, you know, I was just so concerned with how individual players were doing it that it was. You know, ruining the sport for me. And I'm sure there are a lot of people out there listening, period. But there are a lot of people out there listening who play fantasy sports and love it. And I used to love it. But I'm with you, man.
You know it's it's freeing. Yeah, I just, I don't know what it is. It just decided not to do it this year and there's a certain, you know, freedom aspect to it. Anyway, all right, let's let's actually talk about idea access management. And get us back on track here. Today we're going to talk about a topic that was submitted to us by Neil who listens to the show. Certainly appreciate his e-mail.
Let me go right into here. What he writes, 1 area that I think would be pertinent to discuss is around the managing of identity and a multi cloud environment. There is a growing movement toward vendor agnostic use of cloud services and this drives some new thinking around how we approach identity. Do we centralize or distribute identity management? And he thinks that make a good subject which I absolutely agree with. So wanna let's let's start off with you know why do companies
have multi cloud environments. Morgan, do you want to take a stab at that? And then Jim, I'll chime in. My assumption would be that, you know, they have different platforms, different languages that they're using, and they're trying to sort of sequester each one of those to try and make it as secure as possible instead of integrating them all together in a single cloud instance. I think that makes sense.
Yeah, no, that's a good answer. You know, Jeff, what I've found is most clients that I work with. Are either in one of two camps, they're either in a single cloud environment, so they're using something like AWS or Microsoft Azure. And those are you know definitely the two that I see the the largest uptake on at least the the client base that we've been working with or they're in a multi cloud and they have more than one.
So they have AWS and Azure hosting and so the ones that I find that are in that second scenario and. And to be honest, I'm not an expert in the features of a WS, the features of Azure or any of the other cloud platforms, but from, you know, the the level that I'm at, the feature, there seems to be a lot of feature parody.
I'm sure there's people out there pulling their hair out me saying that, but you know, for the most part I'm finding that most clients aren't choosing a WS or Azure based on, you know, this feature or that feature, but more. Which company they align with better now where I see the, the situation where a client has multiple clouds, maybe they even have multiple kind of instances within the same provider.
It's kind of been thrust upon them in that their organization you know grew through acquisition or merger or they you know purchase some software that. That was on one of the clouds and they were already on the other cloud or that you know some decisions were made within their organization. One part of the organization went Microsoft, the other part went a WS. Now they're coming together and kind of starting to manage IT
together. And so in other words, they're they're kind of thrust into that situation. They really choose multicloud. It just kind of happened. Yeah, I see as a look at like from a use case perspective, right. If you're and the the idea that there's different parts of the business that have different use cases kind of places what you just said if you're on the SharePoint side or if you're you know e-mail, you're probably familiar with Azure from a cloud perspective.
But there might be someone who is more on the Google side because of the strength of the analytic side that they might be having. So they're more familiar with that. They might have gone off and built something Google's Cloud Platform, whereas you know, developers might be looking at a WS and spinning up, you know, services there. So pulling things together is certainly you know part of the challenge I think that comes along with it, but in my mind I think it's it's, it kind of goes
with that use case, right. So if you're an Office 365 shop, you're on Azure, you know whether you whether you like it or not, you're already using Azure from that, from that approach and then it becomes that that question of okay, well we're already using here right land and expand, which is you know the the approach many software vendors will take.
Is why don't you use you know Azure for the rest of your cloud services whereas company might have you know other pockets of a WS and that's that's I think that's pretty common. I think a lot of companies try to consolidate on one. But I like the security aspect that Morgan you mentioned before around having things in kind of a little bit of different silo where you don't have all your keys in one castle.
So yeah, I think there is benefit to that as well, using the right tool for the job rather than trying to make you know, one. One service meet all your needs when it may not, may not be the best for the business.
Yeah, absolutely. If I could just jump in and mention something interesting that I noticed when you guys were discussing that was that it's almost like there's this sort of resistance in a sense to complete migration to cloud infrastructure because when you think of implementation of a cloud, it's really dissolving the traditional. Perimeters that we've seen that have relied on things like a firewall and VPN, it's just those just aren't as viable
anymore. You know you're looking at a cross-platform system where you're trying to simplify the IT stack. That elimination of the perimeter is gonna demand some sort of seamless implementation with a centralized user management tool and I. It almost sounds like companies are kind of afraid to do that, and they're trying to almost reestablish perimeters where they just tried to migrate to a fragmentation of it. Yeah, I think the perimeter's gone at this point.
I think that's a losing effort. If you're trying to establish printer on the cloud, Jim, what are some of the problems that you see? If you're taking a multi cloud approach. Well, I think the the biggest problem is the same if you have a single cloud approach which is but you know it's it's obviously compounded. The base problem is the number of secrets or credentials that it takes to run a large cloud environment.
You know you have secrets for secrets or credentials for the console to access infrastructure. Within your applications, they're embedded within configuration files or embedded service accounts. So the volume, the volume of the number of credentials that you have to manage is in in kind of a controlled fashion just becomes such a a major effort that that's really the problem.
And when you go to a multicloud, now you've compounded that you have as many as twice as many secrets that you need to manage. Mm HM yeah, there's a visibility issue too, right? If it's not being if the cloud isn't being managed centrally right, some areas probably have different procedures and processes and policies for their own cloud, right? AWS might be managed different than Azure or Google and you may
not have that visibility. To know who has access to what was really kind of foundational for any IM program which it would be part of the security strategy. Yeah, I mean, think of how how much companies struggle to. Comply with their own policies in terms of password rotation when it comes to service accounts, you know now you're looking at a new environment that often times you know a cloud environment that spun up without information security
having a handson role. Now I'm talking in generalities, right? Not every organization spun up their cloud infrastructure that way, but now you've got thousands of. Credentials that have to be managed and passwords that need to be rotated in compliance. And you may or may not have a technology solution supporting that. So I think that's really the problem. And then when you have multicloud, they just picked up and repeated that the same kind of problem in a second place or or more.
Or you could be talking about an internal private cloud. No matter how you look at it, the more places that you have to manage all these credentials, the harder the problem becomes to. Manage. So it sounds like an answer might be some sort of centralization strategy across the cloud or at least from a management standpoint. I mean that's that's the answer to you know. So I think this gets to Neil's question is using you know should we take a centralized approach or distributed approach.
I'm definitely in the camp of a centralized approach. I want centralized command to control centralized visibility and do who has access to what what they've done. And I want to put together some guidelines or best practices that I can you know put into effect in in terms of managing those identities within the cloud.
And you know I've got some some topics that I'd like to dive into or or kind of best practices that I think that you know and and kind of taking an approach of you've got to walk before you run. Obviously, people who are listening to this podcast could be. In different organizations that have that are a different point in their life cycle that have different types of applications
are running in different clouds. So I'm going to kind of start at the most basic level in terms of here are the approaches that I think need to be tackled and then we'll get into the more advanced stuff all. Right, let's hit it. What's #1? OK, so starting on you know from the basics strong authentication practices, so. You know, starting with the assumption that you've got good
practices for managing identity. So just thinking of your employees, including the population of people who do administrative developer functions in the cloud, that you've got good life cycle management or identity
governance practices. For those people today, you know who works here, who gets access to what And most importantly, when they leave that, you're cutting off that access if you have that and you kind of. Centralize that, say around your Active Directory, then you can plug in your access to the cloud through your corporate single sign on solution or Pam
solution. I think you know either one of those technologies is kind of trying to solve this problem, but what I see the most is organizations starting with managing the console kind of the management interface for their cloud and. Regarding that providing single sign on to that with their SSO solution, so like pop there or ping or or one login or something like that and then ideally on top of like a Pam. Solution work with with that approach as well something. Like, I mean a Pam.
Cyber or Cyber? Yeah, a lot of those, a lot of those vendors have solutions developed around Azure and AWS specifically. I think AWS is probably the one that. I see addressed the most, but I think every solution that's trying to tackle this problem is really focused on providing a solution for a WS as well. It's Microsoft, so yeah, there are there are solutions out there that would allow you to use your Pam solution, which has
its own set of benefits. Those benefits are kind of more down the line of. More advanced benefits and what I was planning on going through at the moment, because what I wanted to talk about next was, you know with authentication. So if we're just talking about access to the console at the moment and providing single sign on using your account that has good I GA practices around it. That's getting disabled when you
leave the organization. On top of that I want to layer multifactor authentication because. You know your your web console is going to be available over the open Internet, and we want to make sure that we're providing a very strong authentication to log in. So you've got MFA, you got strong credentials. Morgan, I know you had some experience working through AWS. When you're logging into AWS, did you did you have MFA enabled when you were trying to get access to the console?
So when I was setting up access to the console, I actually because I directly signed in through Aws's web browser, I did not have to do multi factor. Okay. So that might be a recommendation for a former former client, a former colleague, right? Yeah. Really. Yeah, Really. At this point, password only isn't good enough, right? I think that's kind of like preaching something that we say all the time. You got to put MFA everywhere as much as you can, especially on
the cloud. You know, it's like every week there's like a new article around how you know, someone's cloud got breached. You know S3 bucket wasn't configured correctly and it was exposed. I mean there's just, there's so many things that can go wrong and I think that's what scares maybe some of the people who may be more hesitant to adopt the cloud, going back to a point where you know, Morgan, you made earlier, but it's coming.
I mean, you just can't start putting, you know, racks and racks of servers in your environment where you've got to do a good job of securing access to them. And you talk about authentication and and I from my perspective, I look at it as you've got to know what you've got before you can protect it. So you got to know who has access to what. You got to know what all the
different counts are. Especially if you're working off the compounded problem where you're using multicloud and you have different, you know, vendors get that inventory in place, know what the accounts are, know what the permissions are, start to figure out which ones are human and which ones are machine, right. So a lot of development takes place, so you want to make sure that you identify.
You know what's actually controlled by a person will might be more programmatic and then I would look to centralized as well. So I certainly agree with that approach. Maybe putting something in front of it like the SSO solution makes sense, and then using the MFA that's part of the SSO solution to get access to the cloud environment in my mind would probably be a good, you know, first step towards that. Yeah, I mean, that's what I
really. Feel strongly about is that you know from a console perspective, because I think that's where someone can inflict the most, the most damage, right? They can settings, they can allow themselves access to many of the, you know instances, the server instances or the platform services through the console. So if they can get into the console with a very, you know, very strict role or a very high level role, they could. Do a lot of damage.
So it's kind of basic blocking tackling of using your SSO solution, MFA, strong password policy and then using any other policies that make business sense. I mean there, if you don't, you shouldn't have people accessing during certain times of the day or from different IP ranges than your corporate network. Then go ahead and put those policies in place. Anything you can do to restrict access to just those folks that should be accessing? That environment, all the better.
And one of these vendors also have things like conditional access right, so you can do things around geolocation, you know, device fingerprinting, you know, that sort of thing. It's becoming pretty commonplace today, yeah. Yeah, I remember when that used to be like, ooh wow, we're cool because, you know, we can do this and others can't. But now it's almost a standard feature amongst most. Right, Access management providers. So now it's kind of looking for ways to differentiate between
those. You know I see things that like Casha Corp, you know they specialize in you know cloud management, DevOps that's those sorts of things that might be interesting to look at. One area that I think is has a lot of potential would be more of a like a just in time provisioning of Access where. People don't have permissions
all the time, right. They get them just when they need them and then those permissions are pulled back or you know what are the roles are the entitlements are they give them access. You know there's products out there like plain ID. You can even do something you know through it through an IGA tool, identity governance administration tool like you have potentially sale pointing or savians or things like Oracle or I BM you know those sorts of
right. It's a lot more complicated though when you're trying to do it that way because you really have to know, you know, what are the permissions and then who's going to approve it. If it's something that's critical from like a time frame perspective, you know, is that approver available to put that in there. We see these challenges sometimes of a privileged access
management side too, right? Just even inside the firewall, people getting access to servers and there's this stigma of red tape that kind of goes around privileged access management processes that could easily, you know, happen on on the cloud side too. Right. Yeah, we're, I think privilege access management really gets you the most mileage is beyond just accessing the console when you start getting into managing your server instances and managing the accounts that have access.
So one of the other tips or keys that I have is, you know, making sure that each person. Who has to access servers has their own set of credentials that you're not sharing credentials over a group of people. So for example, if you're using a Linux instance on on the a WS EC2 server, those keys should be individually individually provisioned per person. So private keys should be
private to the user where? Privilege access management system could be really advantageous when it comes to managing those instances is to allow temporary access. Person doesn't actually need to know the password to the account on that server. And then of course you could set the the firewall rules on the console to only allow the only allow. The IP address with the IP range that the privilege access management server exists on to
actually access the server. So then you have some network access controls, you know, additional network access controls guarding access to that server. So some good and that's kind of basic blocking and tackling for
the enterprise. So a lot of the best practices for managing your server environment in the enterprise move over to. Managing the servers in the cloud as well Jeff, one thing you mentioned about Hoshi Corp, I mean what I would recommend for anybody who's listening to go out to their website, watch some of the the videos that they have posted their their tech talks with their their Co CTO's.
I mean those guys are both really, really bright and and they really understand the space and they can walk you through a lot of the ways to approach. Now their focus is primarily I think around managing DevOps, managing really secrets in the in the cloud. And the secrets a lot of times are go back to if you're looking at this from a developer sampling, you're publishing applications out to the cloud.
But I think that's a lot of what we're talking about today, managing A multicloud environment. So I think that's a really good vendor to bring up. Relative to this discussion, you know I think that DevOps is something that you don't want to forget about. How do you deploy apps without hard coding secrets? So you look at technologies like Hash Core. It's a way to have your applications programmatically go out and fetch your secrets rather than having to hard code
them into configuration files. In the same with your DevOps tools like the Kubernetes not having to hard code all those credentials. Into into something that can be seen by multiple people within the organization. Yeah, that takes a lot of work though too, because if you haven't built out applications with that in mind, right.
If more of like a legacy type approach trying to go back and reconfigure applications to use the programmatic means to pull keys from vaults and those sorts of things can take some time. So it's definitely not something that happens from an overnight perspective. But I think I think Ashley Corp would be a good one to look at. You know maybe something like Plain ID as well if you're looking for more like a just in
time provisioning. I think they have some interesting use cases that that might be helpful for people who are looking at managing access to cloud environments. The other thing I think you brought up a good point about, you know, it's a lot of work. I don't think that I am program manager can go in and and and you know be confrontational if you will, about trying to implement security. You really have to partner with the development team.
They have to see the value and having checks and balances and see the value in. You know, the visibility that they can get and the manageability that they can get. A lot of times you run into kind of the mindset that, well, there's only 10 people in the department. They've all worked here, you know, 3, three or more years. We trust them. The thing is, some security is, you know, not about trusting people, it's about being, you know? Being able to not have to rely
on trust. It's being sure that you have the security controls that everybody knows that hey, if you try to do something, we're going to know about it. And I think from an IM program manager perspective, the way I'd look at it is to try to partner with the manager of applications because I think that, you know, they're going to have to adopt this technology more or less willingly for it to be a success and. They should look at the I M team
as a partner. Somebody can provide administration of that of these platforms and be a proper checks and balances that. Can allow them to focus on development and not have to focus on security as much, right. So I think hopefully that helps kind of put at least our opinions around that for Neil and maybe other folks who were having some more questions.
I think to sum it up right, we're we're fans of centralizing it, but you got to have good policy procedure you know back ending that you know the right kind of technology approach and how you'd want to manage the permissions and making sure you don't forget about humans and non humans, right the programmatic side of things, DevOps etcetera, getting access
to the cloud. I'd like to kind of pivot back a little bit to Morgan and kind of talk a little bit about her background, cuz I think she's got kind of an interesting story where you know how people, if you remember one of our first episodes was, you know, how people got into I M most of us kind of fell into it. And I think Morgan's another good example of that. Morgan has an amazing LinkedIn profile, by the way, which I will definitely link in the show notes. So kudos to you.
Morgan definitely shows off some of the writing skills there. Maybe you can talk Morgan, about how you got, how you, how you know, how did you get into I am I guess let's start there. Yeah, sure. So as I mentioned kind of before the call, I was an English major, originally graduated and did some writing for online news journals. But there was a shift to paying writers in terms of publishing where, you know, there was no actual monetary value attached
to your quote, UN quote payment. So from there I kind of pivoted and went into code. Someone who obviously has a respect for language. I figured the language of computers might be something pretty fascinating, and I was not wrong. Definitely in some regards kind of being a professional student, which I loved, I started attending the local weekly OWOSS meetings that we have in Austin.
Through that, I met someone who. Is one of the board members for a hospital application called Open EMR, and that's open source and charity based. All the developer activity on that is out of people's own pockets and time through that, the person who kind of recruited me onto the project saw how. Willing I was to learn and to kind of experiment with things.
So he kind of threw me towards the AWS implementation where we migrated the patient document database to Cloud Native and that's really how I fell into Identity Access Management and here you are. How long did it take to do that migration? Gosh, I'm gonna say a couple months. Maybe two months And that was what re architecting the application, moving data stores
around. Yeah, my personal involvement with it was a little more spotty because I was learning and self teaching and also working on codebase infrastructure at that point as well with Open EMR. So I was kind of being thrown around there. I think that's fascinating. It's such an interesting pivot to go from English major writing into technology like that, I guess. What are some of the languages that I guess what was the first language that you learned on the IT side of things?
Yeah, so when I first got interested in this. And I say this as in coding in general. I went to OWASP and I was initially just filling an A notebook as a dictionary basically with terminology and I was like OK, does anyone have any recommendations for what I should start with? And someone said Python, so that's actually where I started. I wish I would have started with
like. Code Academy's command line, because my knowledge quickly became kind of Swiss cheese esque, and they had to go back a lot of times, kind of backtrack and fill in knowledge holes to understand really why things were happening and how they happened. But Python was first, and then I moved on to HTML, CSS, SQL. That was fascinating. Jim, I think you probably have a
question or two. Yeah, so actually one of the things I just did want to close out one other last point that I wanted to make on the best practice. I think it's just around logging and make sure they have logging centrally set up to identify problems and and setting up alerting and it kind of triggers me into another thought so. One of the things I I started off this discussion around why organizations end up in multicloud and I said, well the
clouds seem pretty comparable. So in other words, if you're down kind of the checkbox list of, you know, does it have a Nosql database, does it have logging, It's like yes, yes, yes, they all operate a little bit differently. You know, they mostly follow some open standards and they have some proprietary connectors and so. It's probably not super easy to just pick up an application and run it in both environments and expect that it. You can't only do that at a very thin level, right?
You have to integrate to the logging solution. So at at many of the tiers of the application you have to make them specific to the cloud that you're running in. And that's why I think it makes it harder to consolidate clouds as well as like you can't just. Pick up all your applications in one. If you're using the platform services of the cloud, you're running everything on server
instances, sure. But if you're using the logging service of the of your cloud provider, when you migrate that application from, you know, from AWS to Microsoft or vice versa, you're going to have to reengineer that application some to work with the logging service of your new cloud.
So. That was just something I wanted to throw in there as well is that, you know, the idea of multicloud will probably be around with us for a long time because it's not just as easy as moving a bunch of server instances from one environment to the other. Yeah, I can't believe it. I totally skipped over the fact that you gotta be able to prove everything right, So I'm glad you brought us back to that. No, no problem.
Yeah, actually with that that brings to mind, you know, identity federation in the cloud trail with AWS where you know you have a log of information about people who even requested in based on their IAM identities. So when you have decentralized logging, you have that single point of access to all salient logs that are created across accounts regions. Which is really critical for
security, right? But if it's fractured with a distributed database, I would think that you really lose a lot of data integrity because of the complexity introduced there. And then I would question kind of handling failures. You know how you distinguish site failure and link failure? Yeah, and one of the things that the. Applications across. Across multiple clouds.
So this is one of the things that I've been thinking about is that if you have a cloud like if one of your goals is to distribute an environment, distribute an application, I don't feel like you have to have it running at AWS time. Microsoft. So if one goes down, the others available because if you look at AWS or Microsoft, they've got data centers in around the world. So I guess you know, if you're really paranoid about your, you know. The entire company going down,
that's one thing. But you know from a geographical load balancing perspective, they've got data centers in different regions of the US and throughout the world. So my thinking is that you know if you're, if you were starting out today, I'm like let's start our our migration to the cloud, you'd pick one vendor and spin up services in. More than one geographical location? You wouldn't say Hey, let's go to two different vendors in case
we lose a vendor. Yeah, you don't want to overcomplicate it, especially if you're just starting out. Right. And then I mean, if you're going to go to the cloud, I mean it's kind of like level one is just spinning up server instances. The real benefit you get is if you get a level 2, Level 3, which is to leverage the platform services for your applications. So if you're using a. A common logging platform. If you're using a common no SQL database or SQL database, but
it's as a as a service. Again, those services are going to look slightly different from cloud to cloud or from vendor to vendor and your applications aren't going to be able to point exactly the same way across multiple clouds. Right on. I think that's probably a good spot. We can leave it for now. I certainly appreciate the conversation. Hopefully Neil and others get some value out of what we talked about today. Morgan, appreciate you taking the time to join us. Welcome to the team.
Welcome to the party. Yeah. Thank you for having me, Jim. Go Bears. Go Bills. Right Morgan. Yeah, Go Bills. Kind of, kind of. All right. All right. We're going to leave it there. Appreciate folks taking time to listen to us. Hopefully you got some value out of it. Feel free to like, subscribe, listen, tell your friends, share the show, and we'll be talking to you on the next one. You've been listening to the
Identity at the Center podcast. To access all episodes, visit identity@thecenter.com.