devopsy.kinsta.cloud

Tag: identity management

  • SIAM

    SIAM

    — ROELBOB

  • SSH Key Management and Your Organization

    SSH Key Management and Your Organization

    It always starts out the same way: a few machines, a few users and a few SSH keys to manage. You manually copy their keys (and your own) to the appropriate machines. You might even say, “Screw it,” and share one key for root access. Admit it. It’s OK. Well, no, it’s not OK, but we all do it at some point, even though we know better. Like pouring grease down the drain: We know we shouldn’t do it, but sometimes it’s just so much more expedient.

    Anyway, you’re lucky enough that your company starts to scale and things start to get more complicated. More users, more servers, tons more keys. Like having too many kids at a birthday party: You start spending all your time making sure they have ice cream, they don’t fall off the trampoline, they don’t get into fights. You’re spending way too much time managing your users and their keys, so you realize you need some sort of system to keep everything coordinated. Often this starts off as an Excel spreadsheet tracking who has what key on what machine (another thing we all do but don’t like to admit to our friends). That’s a start, but that’s just one of many things that you need for SSH key management, and the less manual the process, the better.

    Centralized Store of Identities

    First, let’s admit that Excel spreadsheets really aren’t sufficient to track who can access what on your servers. Without centralized key management, you’re likely to have temporary accounts that are forgotten and hang around forever. You’ve also got the problem of rogue users: One of the users you authorized users goes around you to add someone else and you as the administrator have no idea. You want to have one source of identity for these machines—one place to add, one place to delete, one place to audit.

    Provisioning New Users

    If I’m adding a user a month, sure, I can go and add peoples’ keys to each machine manually. Of course, this presupposes that you’ve got the public key from the user and have it to move around. Which presupposes they’re savvy enough to manage making keys themselves. A key management system should make this process simpler for you, reading from your identity store and putting them onto the appropriate machines.

    Deprovision Departing Users

    If you have someone leaving on good terms, it’s just good practice to remove their keys from your servers. It keeps things clean and secure. If they’re leaving on not-so-good terms, though, you better know where the keys are on every machine and be able to remove them quickly. This also reiterates the need for keeping separate keys for all of your users: If they have the private key for root, you’re going to have to not only get that key off the machines but also hand out the new key to everyone that is supposed to have access to the shared account.

    SSH Key Rotation

    Keeping the same key around makes you more vulnerable to attack if an old key is compromised. The PCI DSS standard says that keys must be rotated at least annually. Making this as easy as possible for the user is important, and you must have someplace to record when each key was last rotated. For a lot of organizations, this is probably that Excel spreadsheet somewhere that’s dusted off right before an audit. Doing this right—rotating all your keys across all your machines on a regular schedule—calls out for an automated process.

    SSH Key Robustness

    Let’s say everyone in your organization is using 1024-bit keys and suddenly word comes down that you need 2048-bit keys instead. Having a key management system is going to help coordinate the update. Otherwise, you’re going to be looking at every key on every server (notice a pattern here?) to see which need updating.

    Getting Rid of Defunct SSH Keys

    This isn’t a one-time thing; keys (and users) have a tendency to be provisioned “temporarily” and then forgotten and left on a machine. A good key management system will find and remove these keys—or at least notify you of their existence.

    Allow Users to Self-Service

    Although we don’t want to allow users to willy-nilly add accounts for themselves and each other, we also don’t want to have to create and handle their private/public key pairs and go into every machine and make changes whenever they lose a key or want to update their keys. Ideally, our key management system would allow for (secure) user control of their keys, allowing resets and updates.

    While most of these things are possible to do by hand, it’s just not easy and it will end up taking way too much time. Maybe you can script it—and in fact, many companies do. But many companies used to write their own string libraries, too, and run their own mail servers and manage their own payroll. It’s not the best use of your time.

    — Rajat Bhargava

  • DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    Two megatrends for 2019 and beyond is scale and automation. The identity management space is a perfect example. Considering all of the IP-enabled devices (machines) coming online and the billions of people and their identities, managing these billions and billions takes systems that will redefine scale and, almost by definition, have to be automated.

    Enter ForgeRock. The company is a leader in identity management for both consumer brands, IoT devices and more. In this DevOps Chat, we speak with Peter Barker, chief product officer, about the challenges to scaling at this level and how important identity management is.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Got a nice chat lined up for today. I’m joined by Peter Barker, who’s the chief product officer at ForgeRock. Peter, welcome to DevOps Chat.

    Peter Barker: Hey, Alan, good to be here.

    Shimel: Thank you. Thank you for joining with us. So, Peter, let’s jump right into things ’cause time’s limited. ForgeRock is a company that I think a lot of people have probably heard of, but I don’t know if people are solid, you know, as a rock, on what exactly they do, so why don’t we start with that? Give us just a quick kind of “Who’s ForgeRock?”

    Barker: Yeah, so ForgeRock is recognized as the most visionary and market-leading identity and access management platform, and we serve the largest logos on the planet, solving a variety of use cases. We provide simple and comprehensive solutions for brands to serve their customers, with identity and access, to deepen their relationships with those customers. And as well to provide access management and identity solutions for employee and partner use cases as well, to really allow better productivity and connectivity in the employee base.

    Shimel: Excellent. And, Peter, I always like to ask my guest to give our audience a sense of your own personal journey. How did you come to be chief product office at ForgeRock?

    Barker: Yeah, it’s a great question and I think back on this journey I’ve been on for the last 25-plus years of my career. I originally started out on the customer side of the house in IT, doing systems development, application development for Kinko’s and FedEx, who acquired Kinko’s, but, later, the last 15 years, I’ve been in product companies, focused on enterprise software and security solutions. And that spanned mobile and mobile security, with good technology. I was at Oracle as well, running their identity and security business for a few years. And then, most recently, now with ForgeRock, over the last year, as their chief product officer.

    Shimel: Excellent. So, Peter, you spoke a little bit about ForgeRock’s mission and what’s going on, but one of the things that – I mean, it’s almost intimidating when we think about it. It’s just the sheer scale. You know, we look at ForgeRock and, I mean, you guys are doing everything from managing and working on identities of consumers coming to large consumer brand websites and applications, through to IoT devices. I mean, not to get all _____ and honest, but it’s billions and billions, right? I mean, it almost seems like an impossible job. How do you chunk that up? How do you go Agile on it? How do we manage it?

    Barker: Yeah, no, it’s – yeah, first of all, you’re absolutely correct. The world of identity, digital identity, is just exploding. It used to be, in the early days of this industry, it was around modeling identities of your employees and providing access and having governance around that access, but, as the world has shifted to consumer and business transformation around digital and having to know your customer across your digital channels, then scale started to explode in that direction because you have millions of consumers versus just thousands of employees.

    And now, in the world of things, where you have this entirely new economy that’s emerging, where things are interacting with the world on your behalf or with you, whether it’s smart devices, smart cars, smart payments, smart everything and the gig economy, it means that identity systems have to model the identities of all of those objects that are interacting in this new world we find ourselves in. And that is causing a massive need for scale.

    And, at ForgeRock, it’s been a really rich heritage and history for us to provide massive scale in our products. And we are, today, already solving some of the most demanding use cases globally, around scale and serving customers in this new digital economy.

    Shimel: A hundred percent. So let’s try to – Peter, you probably – I mean, as part of your responsibilities at ForgeRock, you probably have some metrics to put around this. Can you volunteer a little bit without divulging any _____ _____ –

    Barker: Yeah, for sure. I mean, right now, some of our largest customers are already scaled into the hundreds of millions of consumers and associated devices with those people. We have use cases defined right now with a lot of these customers that are pushing north of the billion-user mark – we’re proving that out in our labs – but, as we know, to meet the demands of scale, it really requires a new approach to the software deployment and how software supports the scale needs and becoming much more elastic and on-demand, as well as horizontally scalable, because it’s the only way that really, truly will continue to serve this need, as it continues to grow.

    Shimel: Sure. You know, Peter, I had an interesting conversation this morning with a CEO founder of an Israeli-based startup around AI. And what he was saying is the kinds of scale issues that you’re tackling at ForgeRock, it’s almost too big for the human mind to wrap around. Right? I mean, let alone at the speed. I mean, humans just can’t operate at that speed to conquer that scale. We just – it’s almost as if you need to invent or implement some sort of AI, machine learning, whatever you wanna call it, intelligence, that allows you to operate at that scale. And is that something ForgeRock is kind of building in, do you think, or is it still –

    Barker: Yeah.

    Shimel: Go ahead.

    Barker: Yeah, definitely. And we have a framework in our product called “Intelligent Authentication,” and it’s designed exactly to do what you’re describing, which is enabling our customers to continue to not only meet the current needs of scale, but the customers, they want to make the authentication and authorization function of their architecture be much more adaptive, much smarter, much more dynamic, to a conditional and contextual world that may exist.

    And, for example, our customers think about security and fraud pretty interchangeably. And if you just think about the scale problem around fraudulent activity, so, if you look at these large brands with hundreds of millions of consumers who they’re trying to provide services to, of course, there’s always some element of fraud that goes along with being in that type of business. And so they have to put in some very complicated algorithms and logic and what have you to continuously be evaluating whether a transaction that’s attempting to happen is actually fraudulent or, on the other hand, maybe it’s something going on from a malicious actor perspective, who’s doing something around security or attempting to breach.

    And so this is causing the sophistication of the techniques being used to go after these problems to really continue to elevate. AI and ML is a big part of that. Being able to integrate multiple services, who are all providing these functions into, essentially, a fabric that is evaluating the risk that’s occurring, and being able to do that at massive scale is how our customers are looking at this and they’re demanding requirements around that.

    And our Intelligent Authentication framework in our product really enables that to happen. We have the scale in the core engine. We have the framework to allow our customers to create these very sophisticated approaches to dealing with these problems that they’re dealing with, out there in the Wild West of their businesses.

    Shimel: Sure. Excellent. So, Peter, it’s December. We’re starting to look towards next year and everybody and their mother-in-law has a prediction and an opinion about what this next year’s gonna hold for us. What do you – if you had to make your best guess and place a bet, what do you think the big story is for ForgeRock and the whole identity community, in the next year or short term? Let’s say 18 months.

    Barker: Yeah, so I’ll just cover a few things that I think inform my answer. First of all, there’s some very interesting challenges that our customers are facing, that apply broadly within the market. First is really a skills gap. So, a few years ago, I started tracking a stat around cybersecurity job openings and how many of those are going unfilled and how many are projected to stay unfilled in the future. And the most recent estimate is that, by 2021, 3-and-a-half million cybersecurity jobs are going to be unfilled.

    And, if you think about that, that’s just a massive challenge for enterprises who are gonna have to continue to deal with and advance their security programs and their security capabilities, when there is a labor shortage, in essence, in the market. And what that’s requiring is vendors to provide solutions that increasingly automate their security program and to provide the security solutions in a much more automated way, so that’s one big area.

    The other is obviously cloud. You know, the most recent prediction by Gartner is that 75 percent of organizations, by 2020, will be running in multi-cloud or hybrid cloud environment, so that just keeps on marching on and forward, as we go on in time. And then, finally, our customers continue to wrestle with security and ease, where that balance between consumer convenience and security is always – it’s very delicate and it’s something that our customers are always trying to find the right balance for. And so they’re increasingly looking for solutions that both increase security but also increase the convenience for consumers.

    And so what all of that is really driving, from a prediction standpoint, over the next 12, 18 months, is our customers, they have many of the features that they really need right now and today. What they’re looking for, increasingly, is solutions to solve those problems. And so we at ForgeRock continue to innovate and deliver new, powerful capability, like Intelligent Authentication, as I talked about earlier, but the big, new element of the equation that customers have been looking for is “How can they transform their software delivery model to much more DevOps? How do they transform their identity program to be much more multi-cloud and multi-cloud approach, where they can be protecting workloads no matter where they are? And how can they do that in an environment where they have less people, less skilled people available to do the job and to do it in a much more automated way?”

    So we, on November 30th, we released a big, new release of our software, Release 6.5, which really addresses these three key things that we’re seeing with our customers. With that release, we’re now able to allow customers to dramatically increase their productivity and their competitive advantage and reducing their cost by deploying our software in these new methodologies.

    We’ve begun surveying our customers and, right now, the consensus is that customers can save as much as 25 percent on their implementation cost of software just by adopting our next release, which is a dramatic improvement over what they’ve been seeing before. And this release allows them, by providing some very simple cloud installation packages, to rapidly deploy production-ready software into a multi-cloud environment, in minutes, supporting hundreds of millions of identities. And so we’re just really excited and customers have been receiving this release very well ’cause it’s solving so many of these challenges that I talked about.

    Shimel: Absolutely. Absolutely. Peter, I know ForgeRock recently came out with some new announcements around product and so forth. Why don’t you share with us a little bit?

    Barker: Yeah. So I think, just continuing on with what I mentioned just a moment ago on Release 6.5, what we’ve done to really support the new deployment model that we’re providing to our customers is we’re giving our customers turnkey, complete DevOps-capable software to run in multi-cloud environment. And we’re providing not just images for our customers, but we’re providing all of the artifacts necessary to really do this successfully.

    That includes – we’ve standardized in Kubernetes for orchestration. We provide our customers the Helm’s Charts. We provide our customers not only that, we provide the reference architecture. We provide the reference configuration for them. We also do performance benchmarking and not only do the performance benchmarking but give our customers the performance testing tools and methodologies so that they can integrate that into the DevOps pipeline as well.

    And, finally, we give our customers all of the cost profiles of these various cloud providers – AWS, Azure, Google Cloud, and Red Hat, OpenShift are the environments that we’re supporting with this release. We’re dramatically accelerating what it takes for a customer to deploy these platforms to support the mega-scale requirements that we talked about earlier on this call.

    And the other thing we announced is that we have now surpassed 50 strategic partners in our trust network partner ecosystem. And what this does is allows customers to rapidly integrate some very innovative solutions around strong authentication or biometrics or identity proofing or risk analysis or fraud detection into their programs very rapidly because we’ve already pre-integrated, pre-certified, and pre-tested that they’re gonna work for our customers. So a very exciting release for us, here at ForgeRock, and, again, just having some tremendous response from customers on it.

    Shimel: Very cool. Excellent. Excellent. So, Peter, I think, when we started, I mentioned to you, once we start talking shop, the time goes. And we’re about out of time already, but I’m gonna let you have the last word. So I think we’ve educated some people; we’ve opened some eyes; we’ve talked about sorta what the issues, challenges are; and I’m sure there’re people listening saying, “I’m dealing with this challenge. I need this solution.” What’s the takeaway here? What’s the one thing people, if they’re gonna learn one thing, what do they need to remember out of this?

    Barker: Yeah, I think the one thing I would really encourage the listeners to think about, when it comes to identity, is, for employee identity, that’s a space that’s been very well supported and served for a long time now. But what we’ve seen is, as enterprises and brands are transforming their businesses to digital, they’ve taken identity – some have had good forethought around identity and really have put the necessary identity platform in place to support their transformation, but many have just sorta run ahead on their digitization. And they’re starting to discover that the way in which they’re supporting their customers – the customer journeys, in their digital channels, is just not seamless, and it’s because they didn’t think about the identity challenges that they’d be facing.

    And so the takeaway I’d really encourage is I think almost all brands on the planet, at this point, are in some stage of journey around digitization, digital transformation, business transformation to the new economy. And really take a look strongly at the need to bring in an identity platform to really support that because, if you don’t, you’ll find quickly that you’ll be underserving your customer experiences and your customer journeys. And, in this new world, customers really vote with their feet in the digital world, in terms of brands that they’re doing business with. And so we highly encourage folks to take a look at this.

    Shimel: Excellent. Peter Barker, chief product officer, ForgeRock, thanks for being our guest on this episode of DevOps Chat. Continued success with ForgeRock and we’ll have to have you back on soon to check in on the progress, but, in the meantime, keep us safe out there.

    Barker: I look forward to it, Alan, and thanks for having me today.

    Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps and the Identity Conundrum

    DevOps and the Identity Conundrum

    “Who am I?” It is perhaps the most basic question of consciousness. The answer could be subdivided by aspects of my life story … my career, my family, my beliefs, my education … the list could continue. But since I am unique, the challenge in this digital age is for me to somehow remain unique, and whatever descriptions are used to catalog who I am, I must remain at the center of them all. If my identity is stolen, how does anyone know, that I am who I say I am?

    This question is fundamental to every interaction I have with the digital world. And unfortunately, every system I interact with looks for me to redefine who I am, over and over again for each of them. I create a Facebook profile, a Twitter profile, a LinkedIn profile … and the list goes on again. But yet another weakness of our digital age is that there is no cross-reference between these systems to ensure I am who I say I am. This phenomenon remains true within DevOps tooling as well.

    The Career Identity Conundrum

    Let’s focus on only one aspect of who I am, my career. Who my current employer is dictates what electronic business systems and networks I should have access to. Switching jobs to another employer changes—or should change—the access I have. But getting more specific, what my role is at my current employer should also have an impact on what tools I have access to, and what I can do within them. And as my role changes, my abilities within a tool should change, as well. If I move from practitioner, to manager, to director, my abilities within a given tool should probably diminish, holding practitioners accountable for actions rather than superseding their responsibility by doing things myself.

    Then there is the area of focus I work on. Business segmentation differentiates my work from product or service “A” in contrast with product or service “B.” My role might be an application programmer, or database administrator, but then “who” I focus on within a company is yet another level of differentiation. The business may prefer that teams of people focused on product “A” are restricted from making substantive changes on product “B.” So two different database administrators need two different levels of access within the same tooling, segregated by line of business or product line to accomplish it.

    The Career Consistency Conundrum

    The problem with my corporate identity in the digital age is that it is fluid, like life. In the course of my career I will change employers at one time or another. But beyond this, I will change roles, and/or areas of focus within the same employer over time. I may be assigned to work a “special project” in addition to my normal duties during my time at a given employer. And where DevOps relies upon several types of tooling to facilitate the continuum, this fluidity in my career makes it difficult to keep up with, and can drive administrative costs quite high.

    For example, if I am an application programmer (normally), I will then have certain abilities within the build, deploy and release tools—likely high ability in build, moderate in deploy and low in release. If I am temporarily assigned as a release manager for a different product/service (in addition to my normal duties), it should radically alter my abilities within the DevOps tools, at least for a short time. But when I return to normal duties, the only mechanism that gets my abilities reset to what they should be is a strong process control system. The tools do nothing to facilitate this (no reminders, no examination of HR systems for roles, no look at each other to see what I am supposed to be).

    An Identity Architecture

    It occurs to me that the constants in resolving these kinds of problems are time and who I am. If I could hold an identification construct that identifies myself in career terms—which employer, which role, etc. and for how long—that identity construct could be employed into every system that accepted it. In effect, it would be the ultimate abstraction of user management, transferring the burden from companies and HR departments to the individuals who know, and need to know, the end user.  While companies would still need to interact with my personal identity construct for verification, assent and record keeping, having all electronic systems accept my ID construct takes all of the work out of programming those interfaces, makes permissions and roles common, and keeps up with life’s fluidity.

    In addition, who I am becomes the same in every system that accepts this construct. I cannot define myself as a release manager in one tool and a test manager in another and an application programmer in yet another to give myself god-like abilities in the DevOps tooling at my company. Each tool would examine the same identity construct I hold and receive from it, my normal duties, roles, permissions, etc. I would have a consistent profile across corporate tooling that would reflect my latest roles and use dates (beginning and end) to validate me against their own records.

    An Identity Lockbox

    The trick is, how do I keep this identity construct from being stolen? I believe this is where biometrics begins to play a key role.  Fingerprint technology is commonplace now, even in cell phones, which are usually chained to us like an additional finger or toe. We rarely go anywhere without them. And when carrying them, we use features such as Touch ID to replace the manual keying-in of passwords. If my identity construct was paired between information likely I alone would have and biometrics tuned only to me (retinal scans, fingerprints, etc.), the pairing could unlock the construct for either use or revision.

    Stealing the construct does little good, as without the pairing biometrics, it could not be used or revised. The applications for an identity construct like this are limitless—everything from securing the right to vote, work and collect social security to validating credit card purchases and opening up new social media accounts.  If Facebook employed (or accepted) this kind of construct, it would be more difficult to create spoof accounts of me, as the unbeatable pairing could decipher who really owns a photo, or document, etc. And looking forward, a standardized identity construct such as this could interact with the emerging world of IoT (internet of Things), where devices could know a lot about me, and know it was truly me.

    Impacts to the Bottom Line

    I am not suggesting some wild end-of-the-world scenario where computers control our every move. We already have that in some form or another (see banks – ha ha).  But I am suggesting that in the interest of reclaiming digital privacy we should be moving the ownership of identity constructs back to the people who own them: us. We should each own our own singular construct, keep it up to date and as filled out or complete as we want to, sharing only what we want to. The chief benefit of this would be an increased difficulty in stealing them from us. We can all skip the 666 tattoos, and instead try to reclaim a moniker of privacy by holding our own digital identities ourselves. Using them like a master key that will open systems we “should” have access to and abilities we “need” to have to perform the work assigned to us.

    The upside to corporations is increased security that requires less on their part to maintain. A single set of records with start and end dates validates IDs used or attempting access. The upside to the software industry as a whole is a common interface for logging into an application with discreet identification. It removes the doubt about “borrowing” an ID if unlocking access requires a biometric pair as well. It would allow every application to abstract user management and make it common. Roles would be abstracted. Permissions could remain unique to each application based on their interpretation of the role.

    Moving to a self-maintained identity construct could be taken further for benefits in other areas of our lives. While we have discussed some of how the career portions of our identity might be subdivided and cataloged, imagine for a moment the benefits of having our heath characteristics attached to the same kind of identity construct. Family records, memberships and associations … pick your classification of how a person is described for who they are. Having a way to retain ownership of those things in the digital age is key to keeping our unique position in the world unique. Losing control of those things becomes catastrophic. Where DevOps benefits from a construct such as this is but the tip of an iceberg compared to the benefits society reaps—or at least, our digital society could reap if we pursued it.

    To continue the conversation, feel free to contact me.

     

    — Kristian Nelson

  • User Identity in Focus as Cloud, Device Use Grows

    User Identity in Focus as Cloud, Device Use Grows

    Recently, I had the pleasure of attending SailPoint’s Navigate ’16 identity management conference. I’ve always been interested in the identity management aspect of security. Many of the first wave of identity management vendors launched around 1999, when I started covering information security as a full-time focus. These vendors dealt with all of the identity challenges that we deal with today—provisioning employees and partners to the resources they need efficiently and effectively, keeping systems secured by making certain people can only access the right data and resources, improving user experience through efforts such as single sign-on, managing privileged accounts, and all the other associated challenges.

    While much of identity management is the same, it’s also quite different in how the challenges have evolved. Today there are more systems with identities to manage. As the number of devices increase, that will grow exponentially over the years ahead. Plus, with agile development methods and approaches to IT management such as DevOps, technology development is moving much more quickly. Finally, IT has much less centralized control now over users than it did 16 years ago.

    Here’s how the rapid expansion of cloud and devices are creating a greater need for identity governance.

    Identity Management and Cloud Growth

    I thought managing identities was as complex as it was going to get when corporate LANs erupted into intranets and the web. At the time, re-tooling and scaling directories made for LANs/WANs to the web and web-based services was a challenge. But today, the burst of cloud-based systems, both private and public cloud and software as a service (SaaS), coupled with the many existing on-premises and web-based systems, have made identity management efforts more complex than ever.

    According to the most recent Bitglass Cloud Adoption Report, 48 percent of enterprises now use a cloud-based productivity suite, up from 28 percent in 2014. In EMEA, 59 percent are adopting cloud suites, as are 61 percent in APAC, compared to 48 percent in North America.

    There’s no doubt cloud-based services have increased the number and nature of how identities are created, managed, deleted and governed. And the security of these data and resourced likely comes down to how well identities are managed.

    The Long Shadow Within IT

    As I mentioned above, there is a lot less (like it or not) centralized control in enterprise technology today. More users are bringing their own devices, as we know, and more business managers and users are procuring their own cloud services, from storage and infrastructure to cloud platforms and SaaS applications.

    According to an CIO.com article published last year, CIOs vastly underestimate extent of shadow IT, analysis by Cisco Systems found the typical enterprise has up to 22 times more cloud services running than it believes. The CIOs surveyed estimated their enterprises were running about 51 cloud services. Reality? There were 730 cloud services running.

    I’ve always argued that Shadow IT should be embraced, not fought. It is a way to see what users need and the services they want to use, and it’s a way to engage with users. That’s not to say IT needs to—or should—let Shadow IT be a free-for-all. It shouldn’t. IT needs to manage the types of devices users can select, the services they can use and the data that can be used in those services, not to mention the regulatory and policy compliance checks. None of that goes away.

    But identity and access is a great way for CIOs and IT to help users safely embrace Shadow IT.

    The Challenge of Managing Device Identity

    It’s not just human identities and applications and services. There are more and more IoT devices whose “identity” and set of privileges must be managed as part of enterprise systems management, data, privacy, security and availability. Gartner expects there to be 21 billion connected Internet of Things (IoT) devices by 2020.

    Again, identity is central to managing access and the privileges IoT devices have, as well as auditing use and activity.

    Gartner agrees: “IAM leaders must reconsider how traditional approaches to cybersecurity and IAM work in a world where devices and services are so abundant, in so many different forms and positioned at so many different points within the IT ecosystem,” said Earl Perkins, research vice president at Gartner.

    Based on conversations at the show, it’s also top of mind with most CIOs.

    The Scale of Cloud Services Challenges Identity

    The dramatic growth of apps and cloud services are taking its toll. Years ago, securing apps meant throwing up some firewalls, setting up a virtual private network and providing access control to applications and networked resources. But with the explosion of apps, cloud services, devices and data, such approaches are antiquated. We didn’t know it then, but that was about as simple as security was going to get.

    All of this requires incredibly well-scaled identity management efforts. In addition to the traditional seasonal or event-driven surges in identity management issues, companies could see surges from devices or users accessing systems at all times and from anywhere. Scaling with this requires identity management and directories eventually to be in the cloud. While most enterprises are hybrid now—unless they formed in the past 10 years—there is plenty of legacy, on-premises and cloud needing management.

    However, in a decade, there will be many more large enterprises fully in the cloud, and identity management technology will follow.