1 00:00:06,120 --> 00:00:07,760 Do you know who has access to what? 2 00:00:08,119 --> 00:00:10,520 This is the Identity at the Center podcast. 3 00:00:10,880 --> 00:00:13,760 If you're looking for identity and access management talk, 4 00:00:13,880 --> 00:00:21,280 you've come to the right place. And now on to the show. 5 00:00:28,960 --> 00:00:31,800 Welcome to yet another episode of the Identity at the Center 6 00:00:31,800 --> 00:00:34,160 podcast. Certainly been appreciating the 7 00:00:34,160 --> 00:00:35,600 likes and ratings we've been getting. 8 00:00:35,680 --> 00:00:38,600 If you like what you hear, do us a favor, share the show with 9 00:00:38,600 --> 00:00:42,120 other like minded individuals And you can also e-mail us at 10 00:00:42,120 --> 00:00:44,600 questions at identity@thecenter.com. 11 00:00:44,920 --> 00:00:48,040 I am Jeff and that is Jim's voice you're about to hear. 12 00:00:48,040 --> 00:00:50,320 Jim. Hey, Jeff, survive the 13 00:00:50,320 --> 00:00:52,220 hurricane. It's by the hurricane. 14 00:00:52,540 --> 00:00:55,780 Well, so far anyway. I'm 100 miles inland and that 15 00:00:55,820 --> 00:00:57,100 helped. Yeah. 16 00:00:57,220 --> 00:00:59,260 So then I guess I'm a Hurricane survivor as well too, being up 17 00:00:59,260 --> 00:01:01,060 in the Chicago area. That's right. 18 00:01:01,380 --> 00:01:03,580 Yeah. We're joined today by Morgan 19 00:01:03,580 --> 00:01:05,700 McNamara. She's one of our crack members 20 00:01:05,700 --> 00:01:08,060 of our engineering team here at Identity. 21 00:01:08,060 --> 00:01:10,500 Hello, Morgan. Hey, Jeff, How's it going? 22 00:01:10,820 --> 00:01:12,740 Good. Thanks for joining us today. 23 00:01:13,100 --> 00:01:15,990 Yeah, no problem. So Jeff, I want to clarify by 24 00:01:16,190 --> 00:01:18,750 being a crack member, that doesn't mean you smoke crack, 25 00:01:18,750 --> 00:01:20,270 right? They don't have. 26 00:01:20,310 --> 00:01:22,350 Well, you know, that's a personal question. 27 00:01:22,350 --> 00:01:25,510 I don't think that that's probably right for the podcast. 28 00:01:25,510 --> 00:01:29,270 I think as long as the work gets done, hey man, whatever. 29 00:01:30,790 --> 00:01:32,310 Not that I'm condoning that behavior. 30 00:01:32,350 --> 00:01:36,590 There you go. So today is Thursday. 31 00:01:36,590 --> 00:01:38,470 Do you know what today is, Jim Morgan? 32 00:01:38,590 --> 00:01:40,990 Take a guess other than you know, podcast day. 33 00:01:41,860 --> 00:01:45,100 Thursday there's. It's an olasp day. 34 00:01:45,100 --> 00:01:47,420 It's not that. It is the opening night of the 35 00:01:47,420 --> 00:01:50,780 NFL. Bears, Packers. 36 00:01:51,100 --> 00:01:54,060 My Bears actually are looking good now. 37 00:01:54,300 --> 00:01:57,020 So there's a chance that we might actually beat the Packers 38 00:01:57,180 --> 00:01:58,940 on Thursday Night Football tonight's open season. 39 00:01:59,220 --> 00:02:01,460 I'm very excited about this. Now those teams have probably 40 00:02:01,460 --> 00:02:04,880 played about 100 times. Yeah, and it's relatively even 41 00:02:04,880 --> 00:02:06,560 even though the Packers seem like they've been dominating the 42 00:02:06,560 --> 00:02:11,280 Bears for the last decade or so, the the actual overall record is 43 00:02:11,280 --> 00:02:13,840 relatively close, which is makes it one of the better rivalries. 44 00:02:14,080 --> 00:02:17,120 Yeah, cool. Morgan, do you have a team that 45 00:02:17,120 --> 00:02:23,080 you follow in the NFL? God, out of obligation, I have 46 00:02:23,080 --> 00:02:25,480 to say the Buffalo Bills. All right, on. 47 00:02:26,040 --> 00:02:27,320 Yeah. Go Bills. 48 00:02:28,590 --> 00:02:31,350 My dad is one of the Bills fans, so I get you on that one. 49 00:02:31,670 --> 00:02:35,910 He's from Newfane and Rochester area, so So yeah, the Bills were 50 00:02:35,910 --> 00:02:36,990 his team. Okay. 51 00:02:36,990 --> 00:02:38,830 Yeah, that's like right next to me. 52 00:02:38,990 --> 00:02:42,550 I'm from Buffalo, so try your hardest bills. 53 00:02:44,950 --> 00:02:46,830 Jim, do you follow? The team Eagles. 54 00:02:47,470 --> 00:02:48,830 That's right, Eagles. Of course. 55 00:02:50,110 --> 00:02:53,230 Did you see that the Eagles offensive line did the ESPN Body 56 00:02:53,230 --> 00:02:54,630 Issue? No. 57 00:02:55,350 --> 00:02:56,550 Yeah. So if. 58 00:02:56,870 --> 00:03:02,590 If that's your thing, just not. Clear it's not. 59 00:03:04,630 --> 00:03:09,790 This is the first time in 25 years of NFL football that I'm 60 00:03:09,790 --> 00:03:11,950 not doing a fantasy Football League. 61 00:03:12,370 --> 00:03:14,690 And I gotta tell you, I find it to be quite free. 62 00:03:14,930 --> 00:03:17,050 I'm actually going to be able to watch the games, enjoy them, 63 00:03:17,370 --> 00:03:20,850 rather than wonder, you know, how my running backs did or are, 64 00:03:20,930 --> 00:03:24,530 you know, having second thoughts around not starting one guy and 65 00:03:24,530 --> 00:03:25,810 him on the bench. So. 66 00:03:26,250 --> 00:03:28,410 Yeah, no, no. I stopped doing it about 10 67 00:03:28,410 --> 00:03:30,290 years ago, and I feel the same way. 68 00:03:30,290 --> 00:03:32,690 It was like it's ruining the game for me. 69 00:03:33,050 --> 00:03:35,810 And I did the same thing with fantasy baseball, where it's 70 00:03:36,170 --> 00:03:39,890 like, you know, I was just so concerned with how individual 71 00:03:39,890 --> 00:03:41,850 players were doing it that it was. 72 00:03:42,280 --> 00:03:43,760 You know, ruining the sport for me. 73 00:03:43,760 --> 00:03:45,840 And I'm sure there are a lot of people out there listening, 74 00:03:47,000 --> 00:03:48,960 period. But there are a lot of people 75 00:03:48,960 --> 00:03:52,640 out there listening who play fantasy sports and love it. 76 00:03:52,640 --> 00:03:55,760 And I used to love it. But I'm with you, man. 77 00:03:56,200 --> 00:03:58,920 You know it's it's freeing. Yeah, I just, I don't know what 78 00:03:58,920 --> 00:04:00,360 it is. It just decided not to do it 79 00:04:00,360 --> 00:04:03,840 this year and there's a certain, you know, freedom aspect to it. 80 00:04:04,160 --> 00:04:07,840 Anyway, all right, let's let's actually talk about idea access 81 00:04:07,840 --> 00:04:10,830 management. And get us back on track here. 82 00:04:11,830 --> 00:04:14,430 Today we're going to talk about a topic that was submitted to us 83 00:04:14,430 --> 00:04:17,709 by Neil who listens to the show. Certainly appreciate his e-mail. 84 00:04:17,709 --> 00:04:21,149 Let me go right into here. What he writes, 1 area that I 85 00:04:21,149 --> 00:04:23,710 think would be pertinent to discuss is around the managing 86 00:04:23,710 --> 00:04:25,670 of identity and a multi cloud environment. 87 00:04:25,910 --> 00:04:28,590 There is a growing movement toward vendor agnostic use of 88 00:04:28,590 --> 00:04:31,670 cloud services and this drives some new thinking around how we 89 00:04:31,670 --> 00:04:34,750 approach identity. Do we centralize or distribute 90 00:04:34,750 --> 00:04:36,910 identity management? And he thinks that make a good 91 00:04:36,910 --> 00:04:38,750 subject which I absolutely agree with. 92 00:04:39,550 --> 00:04:43,710 So wanna let's let's start off with you know why do companies 93 00:04:43,710 --> 00:04:46,950 have multi cloud environments. Morgan, do you want to take a 94 00:04:46,950 --> 00:04:49,110 stab at that? And then Jim, I'll chime in. 95 00:04:50,780 --> 00:04:54,740 My assumption would be that, you know, they have different 96 00:04:54,740 --> 00:04:59,260 platforms, different languages that they're using, and they're 97 00:04:59,260 --> 00:05:03,020 trying to sort of sequester each one of those to try and make it 98 00:05:03,020 --> 00:05:07,980 as secure as possible instead of integrating them all together in 99 00:05:08,020 --> 00:05:11,740 a single cloud instance. I think that makes sense. 100 00:05:12,140 --> 00:05:16,100 Yeah, no, that's a good answer. You know, Jeff, what I've found 101 00:05:16,100 --> 00:05:19,300 is most clients that I work with. 102 00:05:20,210 --> 00:05:23,690 Are either in one of two camps, they're either in a single cloud 103 00:05:23,690 --> 00:05:27,370 environment, so they're using something like AWS or Microsoft 104 00:05:27,370 --> 00:05:29,210 Azure. And those are you know 105 00:05:29,450 --> 00:05:33,850 definitely the two that I see the the largest uptake on at 106 00:05:33,850 --> 00:05:37,090 least the the client base that we've been working with or 107 00:05:37,090 --> 00:05:40,890 they're in a multi cloud and they have more than one. 108 00:05:40,890 --> 00:05:45,970 So they have AWS and Azure hosting and so the ones that I 109 00:05:45,970 --> 00:05:48,370 find that are in that second scenario and. 110 00:05:49,030 --> 00:05:52,710 And to be honest, I'm not an expert in the features of a WS, 111 00:05:52,710 --> 00:05:57,350 the features of Azure or any of the other cloud platforms, but 112 00:05:57,350 --> 00:06:01,150 from, you know, the the level that I'm at, the feature, there 113 00:06:01,150 --> 00:06:02,750 seems to be a lot of feature parody. 114 00:06:02,750 --> 00:06:05,470 I'm sure there's people out there pulling their hair out me 115 00:06:05,470 --> 00:06:09,550 saying that, but you know, for the most part I'm finding that 116 00:06:09,870 --> 00:06:15,230 most clients aren't choosing a WS or Azure based on, you know, 117 00:06:15,470 --> 00:06:17,510 this feature or that feature, but more. 118 00:06:17,790 --> 00:06:22,310 Which company they align with better now where I see the, the 119 00:06:22,310 --> 00:06:27,190 situation where a client has multiple clouds, maybe they even 120 00:06:27,190 --> 00:06:31,030 have multiple kind of instances within the same provider. 121 00:06:31,310 --> 00:06:36,830 It's kind of been thrust upon them in that their organization 122 00:06:37,990 --> 00:06:43,430 you know grew through acquisition or merger or they 123 00:06:44,430 --> 00:06:47,070 you know purchase some software that. 124 00:06:48,240 --> 00:06:51,800 That was on one of the clouds and they were already on the 125 00:06:51,800 --> 00:06:56,400 other cloud or that you know some decisions were made within 126 00:06:56,400 --> 00:06:59,120 their organization. One part of the organization 127 00:06:59,120 --> 00:07:01,920 went Microsoft, the other part went a WS. 128 00:07:01,920 --> 00:07:05,320 Now they're coming together and kind of starting to manage IT 129 00:07:05,320 --> 00:07:08,160 together. And so in other words, they're 130 00:07:08,160 --> 00:07:10,120 they're kind of thrust into that situation. 131 00:07:10,120 --> 00:07:13,080 They really choose multicloud. It just kind of happened. 132 00:07:13,460 --> 00:07:16,300 Yeah, I see as a look at like from a use case perspective, 133 00:07:16,300 --> 00:07:19,740 right. If you're and the the idea that 134 00:07:19,740 --> 00:07:21,740 there's different parts of the business that have different use 135 00:07:21,740 --> 00:07:24,140 cases kind of places what you just said if you're on the 136 00:07:24,140 --> 00:07:26,620 SharePoint side or if you're you know e-mail, you're probably 137 00:07:26,620 --> 00:07:28,820 familiar with Azure from a cloud perspective. 138 00:07:28,940 --> 00:07:31,900 But there might be someone who is more on the Google side 139 00:07:31,900 --> 00:07:34,860 because of the strength of the analytic side that they might be 140 00:07:34,860 --> 00:07:35,940 having. So they're more familiar with 141 00:07:35,940 --> 00:07:36,700 that. They might have gone off and 142 00:07:36,700 --> 00:07:39,180 built something Google's Cloud Platform, whereas you know, 143 00:07:39,220 --> 00:07:42,740 developers might be looking at a WS and spinning up, you know, 144 00:07:42,740 --> 00:07:45,620 services there. So pulling things together is 145 00:07:45,620 --> 00:07:48,540 certainly you know part of the challenge I think that comes 146 00:07:48,540 --> 00:07:51,660 along with it, but in my mind I think it's it's, it kind of goes 147 00:07:51,660 --> 00:07:54,300 with that use case, right. So if you're an Office 365 shop, 148 00:07:54,620 --> 00:07:57,020 you're on Azure, you know whether you whether you like it 149 00:07:57,020 --> 00:07:59,460 or not, you're already using Azure from that, from that 150 00:07:59,460 --> 00:08:02,740 approach and then it becomes that that question of okay, well 151 00:08:02,740 --> 00:08:05,740 we're already using here right land and expand, which is you 152 00:08:05,740 --> 00:08:08,700 know the the approach many software vendors will take. 153 00:08:09,080 --> 00:08:12,520 Is why don't you use you know Azure for the rest of your cloud 154 00:08:12,520 --> 00:08:16,320 services whereas company might have you know other pockets of a 155 00:08:16,320 --> 00:08:18,560 WS and that's that's I think that's pretty common. 156 00:08:18,560 --> 00:08:21,520 I think a lot of companies try to consolidate on one. 157 00:08:21,840 --> 00:08:26,560 But I like the security aspect that Morgan you mentioned before 158 00:08:26,560 --> 00:08:29,400 around having things in kind of a little bit of different silo 159 00:08:29,680 --> 00:08:31,520 where you don't have all your keys in one castle. 160 00:08:31,520 --> 00:08:34,600 So yeah, I think there is benefit to that as well, using 161 00:08:34,600 --> 00:08:37,760 the right tool for the job rather than trying to make you 162 00:08:37,760 --> 00:08:41,390 know, one. One service meet all your needs 163 00:08:41,390 --> 00:08:43,549 when it may not, may not be the best for the business. 164 00:08:43,830 --> 00:08:46,270 Yeah, absolutely. If I could just jump in and 165 00:08:46,350 --> 00:08:51,350 mention something interesting that I noticed when you guys 166 00:08:51,350 --> 00:08:55,270 were discussing that was that it's almost like there's this 167 00:08:55,270 --> 00:09:00,510 sort of resistance in a sense to complete migration to cloud 168 00:09:00,510 --> 00:09:03,630 infrastructure because when you think of implementation of a 169 00:09:03,630 --> 00:09:06,270 cloud, it's really dissolving the traditional. 170 00:09:06,930 --> 00:09:10,250 Perimeters that we've seen that have relied on things like a 171 00:09:10,250 --> 00:09:14,850 firewall and VPN, it's just those just aren't as viable 172 00:09:14,850 --> 00:09:17,370 anymore. You know you're looking at a 173 00:09:17,570 --> 00:09:21,130 cross-platform system where you're trying to simplify the IT 174 00:09:21,130 --> 00:09:23,690 stack. That elimination of the 175 00:09:23,690 --> 00:09:27,050 perimeter is gonna demand some sort of seamless implementation 176 00:09:27,290 --> 00:09:30,410 with a centralized user management tool and I. 177 00:09:30,970 --> 00:09:33,930 It almost sounds like companies are kind of afraid to do that, 178 00:09:34,210 --> 00:09:38,490 and they're trying to almost reestablish perimeters where 179 00:09:38,690 --> 00:09:44,410 they just tried to migrate to a fragmentation of it. 180 00:09:44,730 --> 00:09:46,530 Yeah, I think the perimeter's gone at this point. 181 00:09:46,530 --> 00:09:50,090 I think that's a losing effort. If you're trying to establish 182 00:09:50,090 --> 00:09:53,930 printer on the cloud, Jim, what are some of the problems that 183 00:09:53,930 --> 00:09:56,290 you see? If you're taking a multi cloud 184 00:09:56,290 --> 00:09:58,450 approach. Well, I think the the biggest 185 00:09:58,450 --> 00:10:02,490 problem is the same if you have a single cloud approach which is 186 00:10:02,930 --> 00:10:06,050 but you know it's it's obviously compounded. 187 00:10:07,130 --> 00:10:10,970 The base problem is the number of secrets or credentials that 188 00:10:11,290 --> 00:10:14,250 it takes to run a large cloud environment. 189 00:10:15,490 --> 00:10:20,410 You know you have secrets for secrets or credentials for the 190 00:10:20,410 --> 00:10:23,090 console to access infrastructure. 191 00:10:23,520 --> 00:10:27,080 Within your applications, they're embedded within 192 00:10:27,080 --> 00:10:29,920 configuration files or embedded service accounts. 193 00:10:30,840 --> 00:10:34,680 So the volume, the volume of the number of credentials that you 194 00:10:34,680 --> 00:10:38,960 have to manage is in in kind of a controlled fashion just 195 00:10:38,960 --> 00:10:42,560 becomes such a a major effort that that's really the problem. 196 00:10:42,560 --> 00:10:45,880 And when you go to a multicloud, now you've compounded that you 197 00:10:45,880 --> 00:10:50,480 have as many as twice as many secrets that you need to manage. 198 00:10:50,800 --> 00:10:52,880 Mm HM yeah, there's a visibility issue too, right? 199 00:10:52,880 --> 00:10:56,600 If it's not being if the cloud isn't being managed centrally 200 00:10:56,920 --> 00:11:00,000 right, some areas probably have different procedures and 201 00:11:00,000 --> 00:11:03,320 processes and policies for their own cloud, right? 202 00:11:03,440 --> 00:11:07,440 AWS might be managed different than Azure or Google and you may 203 00:11:07,440 --> 00:11:11,200 not have that visibility. To know who has access to what 204 00:11:11,240 --> 00:11:14,360 was really kind of foundational for any IM program which it 205 00:11:14,360 --> 00:11:16,000 would be part of the security strategy. 206 00:11:16,280 --> 00:11:21,120 Yeah, I mean, think of how how much companies struggle to. 207 00:11:21,620 --> 00:11:25,180 Comply with their own policies in terms of password rotation 208 00:11:25,180 --> 00:11:29,020 when it comes to service accounts, you know now you're 209 00:11:29,020 --> 00:11:34,060 looking at a new environment that often times you know a 210 00:11:34,060 --> 00:11:38,980 cloud environment that spun up without information security 211 00:11:39,540 --> 00:11:42,780 having a handson role. Now I'm talking in generalities, 212 00:11:42,780 --> 00:11:45,180 right? Not every organization spun up 213 00:11:45,180 --> 00:11:48,340 their cloud infrastructure that way, but now you've got 214 00:11:48,500 --> 00:11:50,930 thousands of. Credentials that have to be 215 00:11:50,930 --> 00:11:54,730 managed and passwords that need to be rotated in compliance. 216 00:11:55,010 --> 00:11:58,610 And you may or may not have a technology solution supporting 217 00:11:58,610 --> 00:12:00,290 that. So I think that's really the 218 00:12:00,290 --> 00:12:01,250 problem. And then when you have 219 00:12:01,250 --> 00:12:05,530 multicloud, they just picked up and repeated that the same kind 220 00:12:05,530 --> 00:12:09,130 of problem in a second place or or more. 221 00:12:09,330 --> 00:12:11,650 Or you could be talking about an internal private cloud. 222 00:12:12,010 --> 00:12:14,970 No matter how you look at it, the more places that you have to 223 00:12:14,970 --> 00:12:18,170 manage all these credentials, the harder the problem becomes 224 00:12:18,170 --> 00:12:19,860 to. Manage. 225 00:12:20,100 --> 00:12:23,220 So it sounds like an answer might be some sort of 226 00:12:23,220 --> 00:12:26,420 centralization strategy across the cloud or at least from a 227 00:12:26,420 --> 00:12:29,420 management standpoint. I mean that's that's the answer 228 00:12:29,420 --> 00:12:31,780 to you know. So I think this gets to Neil's 229 00:12:31,780 --> 00:12:34,940 question is using you know should we take a centralized 230 00:12:34,940 --> 00:12:36,460 approach or distributed approach. 231 00:12:36,500 --> 00:12:39,380 I'm definitely in the camp of a centralized approach. 232 00:12:39,380 --> 00:12:43,220 I want centralized command to control centralized visibility 233 00:12:43,220 --> 00:12:45,580 and do who has access to what what they've done. 234 00:12:46,950 --> 00:12:50,350 And I want to put together some guidelines or best practices 235 00:12:51,430 --> 00:12:55,790 that I can you know put into effect in in terms of managing 236 00:12:55,790 --> 00:12:57,430 those identities within the cloud. 237 00:12:57,830 --> 00:13:01,230 And you know I've got some some topics that I'd like to dive 238 00:13:01,230 --> 00:13:05,270 into or or kind of best practices that I think that you 239 00:13:05,270 --> 00:13:09,110 know and and kind of taking an approach of you've got to walk 240 00:13:09,110 --> 00:13:12,310 before you run. Obviously, people who are 241 00:13:12,310 --> 00:13:14,470 listening to this podcast could be. 242 00:13:15,700 --> 00:13:19,500 In different organizations that have that are a different point 243 00:13:19,500 --> 00:13:23,860 in their life cycle that have different types of applications 244 00:13:23,860 --> 00:13:26,820 are running in different clouds. So I'm going to kind of start at 245 00:13:26,820 --> 00:13:30,060 the most basic level in terms of here are the approaches that I 246 00:13:30,060 --> 00:13:33,660 think need to be tackled and then we'll get into the more 247 00:13:33,660 --> 00:13:35,860 advanced stuff all. Right, let's hit it. 248 00:13:35,860 --> 00:13:39,380 What's #1? OK, so starting on you know from 249 00:13:39,380 --> 00:13:43,060 the basics strong authentication practices, so. 250 00:13:44,560 --> 00:13:48,160 You know, starting with the assumption that you've got good 251 00:13:48,160 --> 00:13:52,240 practices for managing identity. So just thinking of your 252 00:13:52,240 --> 00:13:55,800 employees, including the population of people who do 253 00:13:56,120 --> 00:13:59,400 administrative developer functions in the cloud, that 254 00:13:59,400 --> 00:14:02,160 you've got good life cycle management or identity 255 00:14:02,160 --> 00:14:05,880 governance practices. For those people today, you know 256 00:14:05,880 --> 00:14:09,600 who works here, who gets access to what And most importantly, 257 00:14:09,800 --> 00:14:12,640 when they leave that, you're cutting off that access if you 258 00:14:12,640 --> 00:14:15,790 have that and you kind of. Centralize that, say around your 259 00:14:15,790 --> 00:14:21,750 Active Directory, then you can plug in your access to the cloud 260 00:14:22,030 --> 00:14:25,710 through your corporate single sign on solution or Pam 261 00:14:25,710 --> 00:14:28,150 solution. I think you know either one of 262 00:14:28,150 --> 00:14:31,790 those technologies is kind of trying to solve this problem, 263 00:14:31,790 --> 00:14:35,070 but what I see the most is organizations starting with 264 00:14:35,390 --> 00:14:40,030 managing the console kind of the management interface for their 265 00:14:40,030 --> 00:14:43,750 cloud and. Regarding that providing single 266 00:14:43,750 --> 00:14:46,750 sign on to that with their SSO solution, so like pop there or 267 00:14:46,750 --> 00:14:50,550 ping or or one login or something like that and then 268 00:14:50,910 --> 00:14:54,910 ideally on top of like a Pam. Solution work with with that 269 00:14:55,270 --> 00:14:57,950 approach as well something. Like, I mean a Pam. 270 00:14:57,950 --> 00:15:02,310 Cyber or Cyber? Yeah, a lot of those, a lot of 271 00:15:02,310 --> 00:15:07,830 those vendors have solutions developed around Azure and AWS 272 00:15:07,910 --> 00:15:10,790 specifically. I think AWS is probably the one 273 00:15:10,790 --> 00:15:14,730 that. I see addressed the most, but I 274 00:15:14,730 --> 00:15:20,010 think every solution that's trying to tackle this problem is 275 00:15:20,010 --> 00:15:22,970 really focused on providing a solution for a WS as well. 276 00:15:22,970 --> 00:15:26,810 It's Microsoft, so yeah, there are there are solutions out 277 00:15:26,810 --> 00:15:30,930 there that would allow you to use your Pam solution, which has 278 00:15:30,930 --> 00:15:34,810 its own set of benefits. Those benefits are kind of more 279 00:15:34,810 --> 00:15:37,500 down the line of. More advanced benefits and what 280 00:15:37,500 --> 00:15:39,980 I was planning on going through at the moment, because what I 281 00:15:39,980 --> 00:15:43,220 wanted to talk about next was, you know with authentication. 282 00:15:43,220 --> 00:15:46,300 So if we're just talking about access to the console at the 283 00:15:46,300 --> 00:15:51,260 moment and providing single sign on using your account that has 284 00:15:51,260 --> 00:15:55,380 good I GA practices around it. That's getting disabled when you 285 00:15:55,380 --> 00:15:58,660 leave the organization. On top of that I want to layer 286 00:15:58,700 --> 00:16:00,820 multifactor authentication because. 287 00:16:01,280 --> 00:16:04,120 You know your your web console is going to be available over 288 00:16:04,440 --> 00:16:07,080 the open Internet, and we want to make sure that we're 289 00:16:07,080 --> 00:16:10,560 providing a very strong authentication to log in. 290 00:16:10,800 --> 00:16:13,160 So you've got MFA, you got strong credentials. 291 00:16:14,320 --> 00:16:18,680 Morgan, I know you had some experience working through AWS. 292 00:16:19,680 --> 00:16:23,440 When you're logging into AWS, did you did you have MFA enabled 293 00:16:23,840 --> 00:16:26,320 when you were trying to get access to the console? 294 00:16:26,780 --> 00:16:29,980 So when I was setting up access to the console, I actually 295 00:16:30,020 --> 00:16:36,100 because I directly signed in through Aws's web browser, I did 296 00:16:36,100 --> 00:16:39,940 not have to do multi factor. Okay. 297 00:16:39,980 --> 00:16:42,140 So that might be a recommendation for a former 298 00:16:43,420 --> 00:16:46,620 former client, a former colleague, right? 299 00:16:47,260 --> 00:16:47,940 Yeah. Really. 300 00:16:47,980 --> 00:16:49,900 Yeah, Really. At this point, password only 301 00:16:49,900 --> 00:16:52,100 isn't good enough, right? I think that's kind of like 302 00:16:52,100 --> 00:16:54,500 preaching something that we say all the time. 303 00:16:54,540 --> 00:16:58,260 You got to put MFA everywhere as much as you can, especially on 304 00:16:58,260 --> 00:17:00,740 the cloud. You know, it's like every week 305 00:17:00,740 --> 00:17:03,980 there's like a new article around how you know, someone's 306 00:17:03,980 --> 00:17:06,339 cloud got breached. You know S3 bucket wasn't 307 00:17:06,339 --> 00:17:08,740 configured correctly and it was exposed. 308 00:17:08,980 --> 00:17:11,619 I mean there's just, there's so many things that can go wrong 309 00:17:12,020 --> 00:17:14,700 and I think that's what scares maybe some of the people who may 310 00:17:14,700 --> 00:17:17,980 be more hesitant to adopt the cloud, going back to a point 311 00:17:17,980 --> 00:17:20,980 where you know, Morgan, you made earlier, but it's coming. 312 00:17:21,220 --> 00:17:24,060 I mean, you just can't start putting, you know, racks and 313 00:17:24,060 --> 00:17:26,060 racks of servers in your environment where you've got to 314 00:17:26,060 --> 00:17:27,859 do a good job of securing access to them. 315 00:17:28,970 --> 00:17:31,250 And you talk about authentication and and I from my 316 00:17:31,250 --> 00:17:34,170 perspective, I look at it as you've got to know what you've 317 00:17:34,170 --> 00:17:36,330 got before you can protect it. So you got to know who has 318 00:17:36,330 --> 00:17:38,210 access to what. You got to know what all the 319 00:17:38,210 --> 00:17:40,250 different counts are. Especially if you're working off 320 00:17:40,250 --> 00:17:43,130 the compounded problem where you're using multicloud and you 321 00:17:43,130 --> 00:17:46,290 have different, you know, vendors get that inventory in 322 00:17:46,290 --> 00:17:49,650 place, know what the accounts are, know what the permissions 323 00:17:49,650 --> 00:17:52,410 are, start to figure out which ones are human and which ones 324 00:17:52,410 --> 00:17:55,170 are machine, right. So a lot of development takes 325 00:17:55,170 --> 00:17:58,490 place, so you want to make sure that you identify. 326 00:17:58,870 --> 00:18:00,710 You know what's actually controlled by a person will 327 00:18:00,710 --> 00:18:04,070 might be more programmatic and then I would look to centralized 328 00:18:04,070 --> 00:18:05,350 as well. So I certainly agree with that 329 00:18:05,350 --> 00:18:07,870 approach. Maybe putting something in front 330 00:18:07,870 --> 00:18:11,710 of it like the SSO solution makes sense, and then using the 331 00:18:11,710 --> 00:18:16,510 MFA that's part of the SSO solution to get access to the 332 00:18:16,510 --> 00:18:19,230 cloud environment in my mind would probably be a good, you 333 00:18:19,230 --> 00:18:22,350 know, first step towards that. Yeah, I mean, that's what I 334 00:18:22,350 --> 00:18:24,610 really. Feel strongly about is that you 335 00:18:24,610 --> 00:18:27,530 know from a console perspective, because I think that's where 336 00:18:27,810 --> 00:18:31,050 someone can inflict the most, the most damage, right? 337 00:18:31,050 --> 00:18:36,730 They can settings, they can allow themselves access to many 338 00:18:36,730 --> 00:18:42,530 of the, you know instances, the server instances or the platform 339 00:18:42,530 --> 00:18:45,450 services through the console. So if they can get into the 340 00:18:45,450 --> 00:18:50,410 console with a very, you know, very strict role or a very high 341 00:18:50,410 --> 00:18:53,800 level role, they could. Do a lot of damage. 342 00:18:53,800 --> 00:18:57,920 So it's kind of basic blocking tackling of using your SSO 343 00:18:57,920 --> 00:19:03,400 solution, MFA, strong password policy and then using any other 344 00:19:03,400 --> 00:19:05,080 policies that make business sense. 345 00:19:05,080 --> 00:19:08,000 I mean there, if you don't, you shouldn't have people accessing 346 00:19:08,000 --> 00:19:11,920 during certain times of the day or from different IP ranges than 347 00:19:11,920 --> 00:19:14,280 your corporate network. Then go ahead and put those 348 00:19:14,320 --> 00:19:18,200 policies in place. Anything you can do to restrict 349 00:19:18,200 --> 00:19:22,120 access to just those folks that should be accessing? 350 00:19:22,510 --> 00:19:25,510 That environment, all the better. 351 00:19:26,470 --> 00:19:28,270 And one of these vendors also have things like conditional 352 00:19:28,270 --> 00:19:31,670 access right, so you can do things around geolocation, you 353 00:19:31,670 --> 00:19:34,110 know, device fingerprinting, you know, that sort of thing. 354 00:19:34,310 --> 00:19:36,430 It's becoming pretty commonplace today, yeah. 355 00:19:36,750 --> 00:19:39,390 Yeah, I remember when that used to be like, ooh wow, we're cool 356 00:19:39,390 --> 00:19:40,950 because, you know, we can do this and others can't. 357 00:19:40,950 --> 00:19:43,670 But now it's almost a standard feature amongst most. 358 00:19:44,470 --> 00:19:46,030 Right, Access management providers. 359 00:19:46,630 --> 00:19:49,190 So now it's kind of looking for ways to differentiate between 360 00:19:49,190 --> 00:19:51,350 those. You know I see things that like 361 00:19:51,510 --> 00:19:55,310 Casha Corp, you know they specialize in you know cloud 362 00:19:55,310 --> 00:19:57,870 management, DevOps that's those sorts of things that might be 363 00:19:57,870 --> 00:20:01,350 interesting to look at. One area that I think is has a 364 00:20:01,350 --> 00:20:03,870 lot of potential would be more of a like a just in time 365 00:20:03,870 --> 00:20:08,270 provisioning of Access where. People don't have permissions 366 00:20:08,270 --> 00:20:10,630 all the time, right. They get them just when they 367 00:20:10,630 --> 00:20:12,790 need them and then those permissions are pulled back or 368 00:20:12,870 --> 00:20:14,790 you know what are the roles are the entitlements are they give 369 00:20:14,790 --> 00:20:16,950 them access. You know there's products out 370 00:20:16,950 --> 00:20:19,150 there like plain ID. You can even do something you 371 00:20:19,150 --> 00:20:22,030 know through it through an IGA tool, identity governance 372 00:20:22,030 --> 00:20:24,750 administration tool like you have potentially sale pointing 373 00:20:24,790 --> 00:20:28,510 or savians or things like Oracle or I BM you know those sorts of 374 00:20:28,750 --> 00:20:30,350 right. It's a lot more complicated 375 00:20:30,350 --> 00:20:33,310 though when you're trying to do it that way because you really 376 00:20:33,310 --> 00:20:35,940 have to know, you know, what are the permissions and then who's 377 00:20:35,940 --> 00:20:37,460 going to approve it. If it's something that's 378 00:20:37,460 --> 00:20:40,580 critical from like a time frame perspective, you know, is that 379 00:20:40,580 --> 00:20:43,180 approver available to put that in there. 380 00:20:43,580 --> 00:20:45,420 We see these challenges sometimes of a privileged access 381 00:20:45,420 --> 00:20:48,020 management side too, right? Just even inside the firewall, 382 00:20:48,340 --> 00:20:51,820 people getting access to servers and there's this stigma of red 383 00:20:51,820 --> 00:20:54,340 tape that kind of goes around privileged access management 384 00:20:54,340 --> 00:20:58,140 processes that could easily, you know, happen on on the cloud 385 00:20:58,140 --> 00:20:59,320 side too. Right. 386 00:20:59,680 --> 00:21:03,440 Yeah, we're, I think privilege access management really gets 387 00:21:03,440 --> 00:21:07,080 you the most mileage is beyond just accessing the console when 388 00:21:07,080 --> 00:21:10,800 you start getting into managing your server instances and 389 00:21:11,040 --> 00:21:13,720 managing the accounts that have access. 390 00:21:13,720 --> 00:21:19,600 So one of the other tips or keys that I have is, you know, making 391 00:21:19,600 --> 00:21:25,230 sure that each person. Who has to access servers has 392 00:21:25,430 --> 00:21:27,990 their own set of credentials that you're not sharing 393 00:21:27,990 --> 00:21:30,510 credentials over a group of people. 394 00:21:30,510 --> 00:21:36,430 So for example, if you're using a Linux instance on on the a WS 395 00:21:36,430 --> 00:21:43,950 EC2 server, those keys should be individually individually 396 00:21:45,270 --> 00:21:48,990 provisioned per person. So private keys should be 397 00:21:48,990 --> 00:21:53,130 private to the user where? Privilege access management 398 00:21:53,130 --> 00:21:56,210 system could be really advantageous when it comes to 399 00:21:56,210 --> 00:22:01,930 managing those instances is to allow temporary access. 400 00:22:02,210 --> 00:22:05,530 Person doesn't actually need to know the password to the account 401 00:22:05,530 --> 00:22:09,010 on that server. And then of course you could set 402 00:22:09,010 --> 00:22:12,370 the the firewall rules on the console to only allow the only 403 00:22:13,530 --> 00:22:16,800 allow. The IP address with the IP range 404 00:22:16,800 --> 00:22:20,160 that the privilege access management server exists on to 405 00:22:20,160 --> 00:22:23,240 actually access the server. So then you have some network 406 00:22:23,240 --> 00:22:26,400 access controls, you know, additional network access 407 00:22:26,400 --> 00:22:29,320 controls guarding access to that server. 408 00:22:29,320 --> 00:22:35,360 So some good and that's kind of basic blocking and tackling for 409 00:22:35,720 --> 00:22:38,480 the enterprise. So a lot of the best practices 410 00:22:38,480 --> 00:22:41,720 for managing your server environment in the enterprise 411 00:22:42,040 --> 00:22:45,210 move over to. Managing the servers in the 412 00:22:45,210 --> 00:22:48,930 cloud as well Jeff, one thing you mentioned about Hoshi Corp, 413 00:22:49,010 --> 00:22:53,170 I mean what I would recommend for anybody who's listening to 414 00:22:53,170 --> 00:22:56,370 go out to their website, watch some of the the videos that they 415 00:22:56,370 --> 00:23:00,210 have posted their their tech talks with their their Co CTO's. 416 00:23:00,210 --> 00:23:05,490 I mean those guys are both really, really bright and and 417 00:23:05,490 --> 00:23:08,770 they really understand the space and they can walk you through a 418 00:23:08,770 --> 00:23:14,020 lot of the ways to approach. Now their focus is primarily I 419 00:23:14,020 --> 00:23:20,460 think around managing DevOps, managing really secrets in the 420 00:23:20,620 --> 00:23:24,660 in the cloud. And the secrets a lot of times 421 00:23:24,660 --> 00:23:28,100 are go back to if you're looking at this from a developer 422 00:23:28,100 --> 00:23:30,820 sampling, you're publishing applications out to the cloud. 423 00:23:31,060 --> 00:23:32,940 But I think that's a lot of what we're talking about today, 424 00:23:32,940 --> 00:23:34,580 managing A multicloud environment. 425 00:23:34,580 --> 00:23:38,100 So I think that's a really good vendor to bring up. 426 00:23:38,490 --> 00:23:41,690 Relative to this discussion, you know I think that DevOps is 427 00:23:41,690 --> 00:23:45,090 something that you don't want to forget about. 428 00:23:45,090 --> 00:23:48,010 How do you deploy apps without hard coding secrets? 429 00:23:48,250 --> 00:23:50,330 So you look at technologies like Hash Core. 430 00:23:51,490 --> 00:23:55,450 It's a way to have your applications programmatically go 431 00:23:55,450 --> 00:23:58,090 out and fetch your secrets rather than having to hard code 432 00:23:58,090 --> 00:24:02,010 them into configuration files. In the same with your DevOps 433 00:24:02,010 --> 00:24:07,130 tools like the Kubernetes not having to hard code all those 434 00:24:07,130 --> 00:24:10,990 credentials. Into into something that can be 435 00:24:10,990 --> 00:24:14,110 seen by multiple people within the organization. 436 00:24:14,390 --> 00:24:16,510 Yeah, that takes a lot of work though too, because if you 437 00:24:16,510 --> 00:24:19,340 haven't built out applications with that in mind, right. 438 00:24:19,380 --> 00:24:24,420 If more of like a legacy type approach trying to go back and 439 00:24:24,780 --> 00:24:28,860 reconfigure applications to use the programmatic means to pull 440 00:24:28,860 --> 00:24:31,260 keys from vaults and those sorts of things can take some time. 441 00:24:31,260 --> 00:24:33,420 So it's definitely not something that happens from an overnight 442 00:24:33,420 --> 00:24:35,620 perspective. But I think I think Ashley Corp 443 00:24:35,620 --> 00:24:37,420 would be a good one to look at. You know maybe something like 444 00:24:37,420 --> 00:24:40,060 Plain ID as well if you're looking for more like a just in 445 00:24:40,060 --> 00:24:41,220 time provisioning. I think they have some 446 00:24:41,220 --> 00:24:44,060 interesting use cases that that might be helpful for people who 447 00:24:44,060 --> 00:24:48,570 are looking at managing access to cloud environments. 448 00:24:48,930 --> 00:24:51,690 The other thing I think you brought up a good point about, 449 00:24:52,290 --> 00:24:55,690 you know, it's a lot of work. I don't think that I am program 450 00:24:55,690 --> 00:25:00,730 manager can go in and and and you know be confrontational if 451 00:25:00,730 --> 00:25:03,250 you will, about trying to implement security. 452 00:25:03,250 --> 00:25:05,890 You really have to partner with the development team. 453 00:25:05,890 --> 00:25:09,570 They have to see the value and having checks and balances and 454 00:25:09,570 --> 00:25:13,610 see the value in. You know, the visibility that 455 00:25:13,610 --> 00:25:15,810 they can get and the manageability that they can get. 456 00:25:16,330 --> 00:25:21,530 A lot of times you run into kind of the mindset that, well, 457 00:25:21,530 --> 00:25:24,130 there's only 10 people in the department. 458 00:25:24,130 --> 00:25:27,690 They've all worked here, you know, 3, three or more years. 459 00:25:27,690 --> 00:25:30,450 We trust them. The thing is, some security is, 460 00:25:30,490 --> 00:25:34,250 you know, not about trusting people, it's about being, you 461 00:25:34,250 --> 00:25:37,350 know? Being able to not have to rely 462 00:25:37,350 --> 00:25:39,910 on trust. It's being sure that you have 463 00:25:39,910 --> 00:25:42,870 the security controls that everybody knows that hey, if you 464 00:25:42,870 --> 00:25:45,270 try to do something, we're going to know about it. 465 00:25:45,710 --> 00:25:50,270 And I think from an IM program manager perspective, the way I'd 466 00:25:50,270 --> 00:25:55,710 look at it is to try to partner with the manager of applications 467 00:25:55,710 --> 00:25:58,550 because I think that, you know, they're going to have to adopt 468 00:25:58,550 --> 00:26:02,870 this technology more or less willingly for it to be a success 469 00:26:03,190 --> 00:26:06,190 and. They should look at the I M team 470 00:26:06,190 --> 00:26:08,350 as a partner. Somebody can provide 471 00:26:08,670 --> 00:26:14,270 administration of that of these platforms and be a proper checks 472 00:26:14,270 --> 00:26:18,190 and balances that. Can allow them to focus on 473 00:26:18,190 --> 00:26:20,870 development and not have to focus on security as much, 474 00:26:21,030 --> 00:26:23,790 right. So I think hopefully that helps 475 00:26:23,910 --> 00:26:26,870 kind of put at least our opinions around that for Neil 476 00:26:26,870 --> 00:26:29,870 and maybe other folks who were having some more questions. 477 00:26:29,870 --> 00:26:32,230 I think to sum it up right, we're we're fans of centralizing 478 00:26:32,230 --> 00:26:34,870 it, but you got to have good policy procedure you know back 479 00:26:34,870 --> 00:26:37,550 ending that you know the right kind of technology approach and 480 00:26:37,550 --> 00:26:40,590 how you'd want to manage the permissions and making sure you 481 00:26:40,590 --> 00:26:43,390 don't forget about humans and non humans, right the 482 00:26:43,390 --> 00:26:47,040 programmatic side of things, DevOps etcetera, getting access 483 00:26:47,040 --> 00:26:50,560 to the cloud. I'd like to kind of pivot back a 484 00:26:50,560 --> 00:26:55,000 little bit to Morgan and kind of talk a little bit about her 485 00:26:55,000 --> 00:26:57,240 background, cuz I think she's got kind of an interesting story 486 00:26:57,240 --> 00:27:01,200 where you know how people, if you remember one of our first 487 00:27:01,200 --> 00:27:04,360 episodes was, you know, how people got into I M most of us 488 00:27:04,360 --> 00:27:06,320 kind of fell into it. And I think Morgan's another 489 00:27:06,320 --> 00:27:10,250 good example of that. Morgan has an amazing LinkedIn 490 00:27:10,250 --> 00:27:13,330 profile, by the way, which I will definitely link in the show 491 00:27:13,330 --> 00:27:14,650 notes. So kudos to you. 492 00:27:14,650 --> 00:27:20,730 Morgan definitely shows off some of the writing skills there. 493 00:27:20,810 --> 00:27:25,090 Maybe you can talk Morgan, about how you got, how you, how you 494 00:27:25,090 --> 00:27:27,490 know, how did you get into I am I guess let's start there. 495 00:27:27,940 --> 00:27:31,060 Yeah, sure. So as I mentioned kind of before 496 00:27:31,060 --> 00:27:36,900 the call, I was an English major, originally graduated and 497 00:27:36,980 --> 00:27:39,580 did some writing for online news journals. 498 00:27:39,940 --> 00:27:44,860 But there was a shift to paying writers in terms of publishing 499 00:27:45,060 --> 00:27:48,660 where, you know, there was no actual monetary value attached 500 00:27:48,660 --> 00:27:52,500 to your quote, UN quote payment. So from there I kind of pivoted 501 00:27:52,500 --> 00:27:58,540 and went into code. Someone who obviously has a 502 00:27:58,820 --> 00:28:02,300 respect for language. I figured the language of 503 00:28:02,300 --> 00:28:05,220 computers might be something pretty fascinating, and I was 504 00:28:05,220 --> 00:28:08,420 not wrong. Definitely in some regards kind 505 00:28:08,420 --> 00:28:13,260 of being a professional student, which I loved, I started 506 00:28:13,260 --> 00:28:17,860 attending the local weekly OWOSS meetings that we have in Austin. 507 00:28:18,900 --> 00:28:23,820 Through that, I met someone who. Is one of the board members for 508 00:28:23,860 --> 00:28:27,980 a hospital application called Open EMR, and that's open source 509 00:28:27,980 --> 00:28:31,340 and charity based. All the developer activity on 510 00:28:31,340 --> 00:28:37,940 that is out of people's own pockets and time through that, 511 00:28:39,060 --> 00:28:43,340 the person who kind of recruited me onto the project saw how. 512 00:28:43,820 --> 00:28:47,020 Willing I was to learn and to kind of experiment with things. 513 00:28:47,020 --> 00:28:51,220 So he kind of threw me towards the AWS implementation where we 514 00:28:51,220 --> 00:28:56,780 migrated the patient document database to Cloud Native and 515 00:28:56,780 --> 00:29:00,900 that's really how I fell into Identity Access Management and 516 00:29:00,900 --> 00:29:02,780 here you are. How long did it take to do that 517 00:29:02,780 --> 00:29:07,700 migration? Gosh, I'm gonna say a couple 518 00:29:07,900 --> 00:29:11,200 months. Maybe two months And that was 519 00:29:11,200 --> 00:29:13,960 what re architecting the application, moving data stores 520 00:29:13,960 --> 00:29:17,840 around. Yeah, my personal involvement 521 00:29:17,840 --> 00:29:22,040 with it was a little more spotty because I was learning and self 522 00:29:22,040 --> 00:29:28,240 teaching and also working on codebase infrastructure at that 523 00:29:28,240 --> 00:29:31,270 point as well with Open EMR. So I was kind of being thrown 524 00:29:31,270 --> 00:29:34,750 around there. I think that's fascinating. 525 00:29:34,750 --> 00:29:42,470 It's such an interesting pivot to go from English major writing 526 00:29:42,710 --> 00:29:46,230 into technology like that, I guess. 527 00:29:46,710 --> 00:29:49,670 What are some of the languages that I guess what was the first 528 00:29:49,670 --> 00:29:53,110 language that you learned on the IT side of things? 529 00:29:53,510 --> 00:29:56,630 Yeah, so when I first got interested in this. 530 00:29:57,450 --> 00:29:59,730 And I say this as in coding in general. 531 00:30:00,610 --> 00:30:06,210 I went to OWASP and I was initially just filling an A 532 00:30:06,210 --> 00:30:11,410 notebook as a dictionary basically with terminology and I 533 00:30:11,410 --> 00:30:14,530 was like OK, does anyone have any recommendations for what I 534 00:30:14,530 --> 00:30:17,770 should start with? And someone said Python, so 535 00:30:17,770 --> 00:30:21,890 that's actually where I started. I wish I would have started with 536 00:30:21,890 --> 00:30:24,690 like. Code Academy's command line, 537 00:30:24,770 --> 00:30:28,650 because my knowledge quickly became kind of Swiss cheese 538 00:30:28,650 --> 00:30:32,330 esque, and they had to go back a lot of times, kind of backtrack 539 00:30:32,330 --> 00:30:35,650 and fill in knowledge holes to understand really why things 540 00:30:35,650 --> 00:30:37,210 were happening and how they happened. 541 00:30:38,010 --> 00:30:45,530 But Python was first, and then I moved on to HTML, CSS, SQL. 542 00:30:45,770 --> 00:30:49,810 That was fascinating. Jim, I think you probably have a 543 00:30:49,810 --> 00:30:54,100 question or two. Yeah, so actually one of the 544 00:30:54,100 --> 00:30:57,540 things I just did want to close out one other last point that I 545 00:30:57,540 --> 00:31:01,020 wanted to make on the best practice. 546 00:31:01,500 --> 00:31:06,380 I think it's just around logging and make sure they have logging 547 00:31:06,700 --> 00:31:11,860 centrally set up to identify problems and and setting up 548 00:31:12,660 --> 00:31:18,300 alerting and it kind of triggers me into another thought so. 549 00:31:18,680 --> 00:31:22,760 One of the things I I started off this discussion around why 550 00:31:23,120 --> 00:31:26,480 organizations end up in multicloud and I said, well the 551 00:31:26,720 --> 00:31:29,280 clouds seem pretty comparable. So in other words, if you're 552 00:31:29,280 --> 00:31:34,440 down kind of the checkbox list of, you know, does it have a 553 00:31:34,440 --> 00:31:37,400 Nosql database, does it have logging, It's like yes, yes, 554 00:31:37,400 --> 00:31:40,400 yes, they all operate a little bit differently. 555 00:31:40,400 --> 00:31:43,440 You know, they mostly follow some open standards and they 556 00:31:43,440 --> 00:31:45,880 have some proprietary connectors and so. 557 00:31:46,320 --> 00:31:52,040 It's probably not super easy to just pick up an application and 558 00:31:52,040 --> 00:31:54,680 run it in both environments and expect that it. 559 00:31:55,040 --> 00:31:58,000 You can't only do that at a very thin level, right? 560 00:31:58,000 --> 00:32:00,800 You have to integrate to the logging solution. 561 00:32:00,800 --> 00:32:06,000 So at at many of the tiers of the application you have to make 562 00:32:06,000 --> 00:32:08,480 them specific to the cloud that you're running in. 563 00:32:08,800 --> 00:32:13,520 And that's why I think it makes it harder to consolidate clouds 564 00:32:13,520 --> 00:32:17,000 as well as like you can't just. Pick up all your applications in 565 00:32:17,000 --> 00:32:18,520 one. If you're using the platform 566 00:32:18,520 --> 00:32:22,120 services of the cloud, you're running everything on server 567 00:32:22,120 --> 00:32:25,320 instances, sure. But if you're using the logging 568 00:32:26,520 --> 00:32:30,640 service of the of your cloud provider, when you migrate that 569 00:32:30,640 --> 00:32:35,520 application from, you know, from AWS to Microsoft or vice versa, 570 00:32:35,880 --> 00:32:38,680 you're going to have to reengineer that application some 571 00:32:38,680 --> 00:32:42,280 to work with the logging service of your new cloud. 572 00:32:42,600 --> 00:32:44,620 So. That was just something I wanted 573 00:32:44,620 --> 00:32:47,820 to throw in there as well is that, you know, the idea of 574 00:32:47,940 --> 00:32:50,620 multicloud will probably be around with us for a long time 575 00:32:50,620 --> 00:32:55,020 because it's not just as easy as moving a bunch of server 576 00:32:55,020 --> 00:32:57,260 instances from one environment to the other. 577 00:32:57,540 --> 00:33:00,420 Yeah, I can't believe it. I totally skipped over the fact 578 00:33:00,420 --> 00:33:03,580 that you gotta be able to prove everything right, So I'm glad 579 00:33:03,580 --> 00:33:06,060 you brought us back to that. No, no problem. 580 00:33:06,530 --> 00:33:10,530 Yeah, actually with that that brings to mind, you know, 581 00:33:10,530 --> 00:33:14,770 identity federation in the cloud trail with AWS where you know 582 00:33:14,770 --> 00:33:17,850 you have a log of information about people who even requested 583 00:33:17,850 --> 00:33:20,930 in based on their IAM identities. 584 00:33:21,450 --> 00:33:24,570 So when you have decentralized logging, you have that single 585 00:33:24,570 --> 00:33:29,370 point of access to all salient logs that are created across 586 00:33:29,490 --> 00:33:33,070 accounts regions. Which is really critical for 587 00:33:33,070 --> 00:33:37,070 security, right? But if it's fractured with a 588 00:33:37,070 --> 00:33:42,510 distributed database, I would think that you really lose a lot 589 00:33:42,510 --> 00:33:46,390 of data integrity because of the complexity introduced there. 590 00:33:46,710 --> 00:33:50,830 And then I would question kind of handling failures. 591 00:33:50,910 --> 00:33:55,350 You know how you distinguish site failure and link failure? 592 00:33:55,950 --> 00:33:56,990 Yeah, and one of the things that the. 593 00:33:57,430 --> 00:34:00,290 Applications across. Across multiple clouds. 594 00:34:00,330 --> 00:34:03,010 So this is one of the things that I've been thinking about is 595 00:34:03,010 --> 00:34:08,130 that if you have a cloud like if one of your goals is to 596 00:34:08,130 --> 00:34:11,409 distribute an environment, distribute an application, I 597 00:34:11,409 --> 00:34:15,090 don't feel like you have to have it running at AWS time. 598 00:34:15,090 --> 00:34:17,570 Microsoft. So if one goes down, the others 599 00:34:17,570 --> 00:34:21,610 available because if you look at AWS or Microsoft, they've got 600 00:34:21,929 --> 00:34:24,010 data centers in around the world. 601 00:34:24,010 --> 00:34:27,449 So I guess you know, if you're really paranoid about your, you 602 00:34:27,449 --> 00:34:30,270 know. The entire company going down, 603 00:34:30,550 --> 00:34:34,270 that's one thing. But you know from a geographical 604 00:34:34,270 --> 00:34:38,909 load balancing perspective, they've got data centers in 605 00:34:38,909 --> 00:34:41,389 different regions of the US and throughout the world. 606 00:34:42,190 --> 00:34:46,270 So my thinking is that you know if you're, if you were starting 607 00:34:46,270 --> 00:34:50,110 out today, I'm like let's start our our migration to the cloud, 608 00:34:50,350 --> 00:34:54,989 you'd pick one vendor and spin up services in. 609 00:34:55,440 --> 00:34:57,720 More than one geographical location? 610 00:34:57,720 --> 00:35:00,720 You wouldn't say Hey, let's go to two different vendors in case 611 00:35:00,720 --> 00:35:03,000 we lose a vendor. Yeah, you don't want to 612 00:35:03,000 --> 00:35:05,040 overcomplicate it, especially if you're just starting out. 613 00:35:05,400 --> 00:35:07,440 Right. And then I mean, if you're going 614 00:35:07,440 --> 00:35:11,200 to go to the cloud, I mean it's kind of like level one is just 615 00:35:11,480 --> 00:35:15,560 spinning up server instances. The real benefit you get is if 616 00:35:15,560 --> 00:35:18,840 you get a level 2, Level 3, which is to leverage the 617 00:35:18,840 --> 00:35:21,080 platform services for your applications. 618 00:35:21,080 --> 00:35:24,080 So if you're using a. A common logging platform. 619 00:35:24,080 --> 00:35:29,800 If you're using a common no SQL database or SQL database, but 620 00:35:29,800 --> 00:35:34,720 it's as a as a service. Again, those services are going 621 00:35:34,720 --> 00:35:37,960 to look slightly different from cloud to cloud or from vendor to 622 00:35:37,960 --> 00:35:41,480 vendor and your applications aren't going to be able to point 623 00:35:41,800 --> 00:35:45,120 exactly the same way across multiple clouds. 624 00:35:45,480 --> 00:35:47,040 Right on. I think that's probably a good 625 00:35:47,040 --> 00:35:48,640 spot. We can leave it for now. 626 00:35:49,880 --> 00:35:51,400 I certainly appreciate the conversation. 627 00:35:51,400 --> 00:35:54,920 Hopefully Neil and others get some value out of what we talked 628 00:35:54,920 --> 00:35:56,800 about today. Morgan, appreciate you taking 629 00:35:56,800 --> 00:35:58,640 the time to join us. Welcome to the team. 630 00:35:58,960 --> 00:36:00,400 Welcome to the party. Yeah. 631 00:36:00,400 --> 00:36:03,040 Thank you for having me, Jim. Go Bears. 632 00:36:06,240 --> 00:36:07,560 Go Bills. Right Morgan. 633 00:36:07,960 --> 00:36:10,960 Yeah, Go Bills. Kind of, kind of. 634 00:36:10,960 --> 00:36:11,840 All right. All right. 635 00:36:12,080 --> 00:36:14,640 We're going to leave it there. Appreciate folks taking time to 636 00:36:14,640 --> 00:36:16,920 listen to us. Hopefully you got some value out 637 00:36:16,920 --> 00:36:18,720 of it. Feel free to like, subscribe, 638 00:36:18,760 --> 00:36:23,200 listen, tell your friends, share the show, and we'll be talking 639 00:36:23,200 --> 00:36:30,000 to you on the next one. You've been listening to the 640 00:36:30,000 --> 00:36:34,160 Identity at the Center podcast. To access all episodes, visit 641 00:36:34,160 --> 00:36:35,800 identity@thecenter.com.