devopsy.kinsta.cloud

Tag: Identity

  • AWS Identity and Access Management (IAM) Roles and How to use Them

    AWS Identity and Access Management (IAM) Roles and How to use Them

    Amazon Web Services relies on the AWS IAM service to govern who is authenticated and authorized to use AWS resources. It plays a hugely significant role in AWS security–and so do its various identities. Let’s look in more detail at IAM roles and how they work.

    What is the Purpose of IAM?

    When you create an AWS account, it has a single sign-on (SSO) identity called the AWS account root user, which has complete access to AWS services and resources. To avoid potentially disastrous issues arising from this kind of unfettered access, IAM allows shared access to the AWS account via identities.

    Based on the security-first model, AWS restricts all actions for all identities by default–apart from the root user. This restriction enables us to manage granular access for identities following the principle of least privilege, so permissions are granted only as required to execute daily tasks.

    What are IAM Roles?

    AWS users, federated identities and AWS roles are the three major categories of AWS Identities. IAM roles are conceptually similar to AWS users, but whereas a user is uniquely associated with a principal(users/apps/etc.), a role can be assumed by anyone who needs it.

    Rather than passwords or access keys, temporary security credentials are provided to whoever assumes the role. This eliminates the overhead of managing users and their long-lived credentials.

    Any of the following entities can assume a role to use its permissions:
    ● AWS user from the same account
    ● AWS user from a different account
    ● AWS service
    ● Federated identity

    Structure of an IAM Role

    The two essential aspects of an IAM role are the trust policy (who can assume the IAM role) and the permission policy (what the role permits the user to do).

    Trust policies use specified conditions to define and control which principals can assume the role. They prevent the misuse of IAM roles by unauthorized or unintended entities.

    Permission policies define what the principals assuming the role are allowed to do.

    Types of IAM Roles

    AWS IAM roles fall into one of the following major categories based on their trust policies:
    ● Service role
    ● Service-linked role
    ● Web Identity role
    ● SAML 2.0 federation role
    ● Custom IAM role

    Service Roles
    AWS services are the trusted entity type for these roles, which are created to allow AWS services to perform actions on the user’s behalf. They do this by inheriting the permissions assigned to the service role.

    You might wonder why AWS services need permission to access each other. It’s because, by default, even AWS services have no access to the resources in the AWS account. However, service roles allow AWS services to access resources based on their requirements.

    Most AWS services rely on service roles for optimal functioning. For example, they allow Cloudformation to create and delete resources on the user’s behalf based on a YAML or JSON file. The Amazon EC2 IAM role is a special type of service role. EC2 relies on an instance profile as a container for an IAM role, which is then assumed by the applications running within the EC2 instance to perform actions the role allows.

    Service-Linked Roles
    A service-linked role is a unique kind of IAM role linked to an AWS service. It simplifies the process of setting up a service by automatically adding all the required permissions for a service to perform actions on the user’s behalf. It is predefined by the service. Most service-linked roles do not permit changes to trust or permission policies.

    Web Identity Roles
    A user assumes a web identity role when they log in to AWS using an identity provider (IdP) such as Amazon and Facebook. Users do not have an identity within AWS itself; in exchange for an authentication token, they get temporary security credentials in AWS that map to an IAM role that is authorized to use the resources in the AWS account.

    SAML 2.0 Federation Roles
    These roles are assumed by users who are included in an external user directory, typically within organizations. This enables federated single sign-on (SSO), so that organizations can give users access to the AWS console and CLI without having to create a separate IAM user for each person. An organization that manages its employees in Microsoft Azure Active Directory could connect to AWS directly and give its users access to the AWS console and CLI based on the permissions provided to the SAML 2.0 federation role.

    Custom IAM role
    Custom IAM roles do not fit any of the other categories and support scenarios other than the ones listed above.

    What is the Time Limit for Assuming a Role?

    An entity can assume a role for as long as the IAM role’s session duration property dictates. For example, if the session duration for a role is set at 12 hours, the temporary credentials will expire 12 hours after they are issued.

    If you assume the role using the assume-role* command, you can specify a value for the session duration using the duration-seconds flag, ranging from 15 minutes to the maximum session duration permitted for the role. The default duration is one hour, but it can be extended to up to 12 hours. The session duration can be adjusted by editing the role.

    What About Role Chaining?

    One role can assume another role in a process known as role chaining. Role chaining cannot extend beyond an hour on the user session; it doesn’t follow the role’s maximum session duration field.

    And Cross-Account Access?

    IAM roles are often leveraged to enable cross-account access – the process of leveraging a principal in one account for access to resources in a different account. Organizations often maintain multiple AWS accounts to segregate environments such as development, staging, test, UAT, and production, and they grant identities from one account permission to access resources in another.

    This could be to process data in the production account and then anonymize and copy it to the UAT account, so that the frequency and attributes of data are the same. This keeps the UAT environment as close to the production environment as possible.

    How do IAM Roles Differ From Resource-Based Policies?

    Both identity-based policies and resource-based policies are permission policies, but identity-based policies are attached to identities such as users, roles, or groups, and resource-based policies are attached to resources such as S3, Amazon SQS queues, or VPC endpoints.

    Identity-based policies specify the actions the identity can take and on which resources, whereas resource-based policies determine who is allowed to access the resource to which they are linked and specify the actions they can perform. Resource-based policies must be inline and not managed. This list provides details of which resources support resource-based policies.

    Where both identity and resource-based policies are present, AWS evaluates them together. An action is permitted if it is allowed in either or both policies. If either policy contains an explicit DENY, it overrides the ALLOW.

    You can provide cross-account access using just the resources policy rather than using a role as a proxy. This is achieved by attaching a resource-based policy on the resource you want to share. This resource policy comprises all the principals allowed to access this resource, in contrast with an identity-based policy, which specifies the resources a principal has access to.

    Using a resource-based policy for cross-account access rather than roles has advantages.

    When a user assumes a role, they cede the permissions they have in the trusted account so that they can secure permissions in the trusting account (account with shared resources). With a resource-based policy, the user keeps their permissions in the trusted account, and they also secure access to the shared resources in the trusting account. The principal can access both accounts.

    AWS IAM Roles Anywhere

    AWS IAM Roles Anywhere is a kind of service role that permits on-prem machines or workloads external to AWS (such as servers, containers, and applications) to access resources on AWS by acquiring temporary security credentials. This completely eliminates the headache of managing long-term credentials.

    Workloads are required to have X.509 certificates issued by a certificate authority, which must be registered with IAM Roles Anywhere as a trust anchor. Though a relatively recent use case, it marks a move toward minimizing the usage of long-term credentials.

    Benefits of Using IAM Roles

    ● No management of long-term security credentials
    ● Support for Single Sign-on (SSO) using SAML 2.0
    ● Support for web identity federation, allowing users to log in via popular external identity providers (IdPs), such as Amazon, Facebook, and Google
    ● Enhanced security posture because you don’t have to rotate and replace short-term credentials (An expiry is already associated with them).
    ● Support for use cases such as cross-account access, Identity federation, AWS IAM Roles Anywhere

    Key Takeaways

    IAM roles are key pillars supporting, not just the IAM service, but the entire authentication and authorization flow. Their value extends beyond applications such as cross-account access, AWS IAM Roles Anywhere, and identity federation, being important for enhancing any organization’s security posture substantially. When used to their full potential, they can be extremely useful in IAM.

  • Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta today made generally available an Actions Integration capability that makes it possible to integrate third-party tools without having to write any code.

    Shiven Ramji, chief product officer for Okta, said this no-code integration capability for the Okta Customer Identity Cloud extends a simpler approach for managing secrets that is invoked via an application programming interface (API).

    At a time when more responsibility for application security is being shifted left toward developers, the Okta Customer Identity Cloud is gaining traction as an alternative for managing secrets more securely, noted Ramji. Rather than developers attempting to manually verify the identity of end users, it becomes easier to manage identity flows within the context of a larger application development workflow using a cloud service, he added.

    In addition to giving developers access to Actions Integration, Okta is also making third-party integrations developed by partners available via the Auth0 Marketplace. The goal is to encourage providers of application development tools to build integrations that development teams can simply download when needed, said Ramji.

    It’s not clear how much influence developers are exerting over how identity is managed as more organizations embrace DevSecOps best practices for building and deploying applications. Regardless of approach, the overall state of application security should continue to improve as developers embrace new methods of managing identity within their applications. One of the issues that frequently creates a security breach is when developers forget to remove secrets created during the application development process before an application is deployed in a production environment. Cybercriminals today routinely scan for secrets that have been inadvertently stored as text within an application.

    Lees clear is the degree to which developers may opt to update existing applications to take advantage of identity management services that can be invoked via an API or whether they will opt to switch to a cloud service for only new applications.

    One way or another, organizations of all sizes will need to find a way to make it easier for developers to manage identities across multiple applications. There is often a tendency to ascribe responsibility for managing identities to development teams without always providing access to a set of tools to manage the process. In about half of the instances in which organizations adopt Okta Customer Identity Cloud, the decision is made by developers, said Ramji. Many of those developers discover the Okta service when they are building a proof-of-concept for their application, he added.

    The other half of the time the decision is made by more senior leaders on behalf of an entire development team, said Ramji. In some of those cases, organizations are even going to far as to create a team of specialists for managing identities across a portfolio of applications, he noted.

    The core issue, as always, is determining how much time and effort developers will want to spend on identity management versus writing business logic code. All things considered, most developers are going to find it a lot more convenient to invoke an API to access a cloud service versus setting up and maintaining a vault full of application secrets on their own.

  • Why You Should Consolidate Your IAM

    Why You Should Consolidate Your IAM

    It’s not often you can get a win that makes your IT processes easier while simultaneously improving your cybersecurity. In fact, oftentimes making improvements in one area (for example, improving IT processes) comes at the cost of the other (cybersecurity). But there’s one area, in particular, where these improvements aren’t mutually exclusive: Identity and access management (IAM). In fact, consolidating the identity and access management technology used in your organization is one of the few ways to simplify and secure against threats at the same time. Let’s see why this is the case by focusing on each of those items individually and then look at the big picture.

    Let’s start with security. Properly managing identity and access is naturally a critical component of a good cybersecurity stance. If you aren’t properly managing access or don’t know who is leveraging your access tools, the rest of your cybersecurity stack won’t be of much help in keeping you out of the headlines. While that’s pretty obvious, the piece that’s easy to overlook is the consolidation of those tools. As organizations grow, they often find that rather than scaling solutions with teams, they pick up additional solutions for new teams, new locations, new vendors and so on. Suddenly, the original corporate VPN is now three, there are five different vendor access methods (all tied to different authentication methods or shared accounts), some users are in Active Directory, some only in GSuite and there are too many local accounts on applications to count. At the end of the day, each path to an application should be tied to a proper access tool with authentication and a known individual identity, but that becomes difficult or impossible to verify. At that point, it takes just a few questions to realize the security risks of disparate access solutions:

    • When something goes wrong, how do you verify who may have had access to that system? How many access solutions could have gotten a user there?
    • When John leaves the organization, how certain are you that all of his access will be revoked?
    • How do you know that all of these solutions are up-to-date with the required patches to remain secure?
    • Is there a comprehensive list of access methods the organization uses, or are you going to find some long-forgotten VPN in the future?

    So, the security implications quickly become obvious. Consolidating on a minimum number of required solutions means you can address those security gaps with simplification. It’s not often that you get the chance to do that in a world where security usually means adding another tool to the stack. The result of consolidating means your users, whether non-technical end users or IT admins, all see improved workflows. Fewer credentials for end users to manage and less chance they’ll need different access tools depending on the system they need to reach. From the IT side, it means your staff can quickly provision or deprovision access. It also means that when something does go wrong, a clear picture of all access to an affected system can be drawn up in minutes, rather than hours or days. When consolidating identity and access management tools, the following should be clear goals:

    • User authentication should enforce multifactor authentication (MFA)
    • Authentication should also include employment verification when third parties are involved
    • Access management should embrace a least-privilege access model, narrowing access to specific applications and even timeframes where applicable
    • An access solution should take into account the various needs of all user profiles at the protocol level. Some users may need a few web services, while others might need the right protocols to manage servers or custom applications
    • IT admins should be able to quickly identify all the access a user has and all the users with access to a given endpoint
    • History and audit is a given

    Keeping these items in mind when consolidating technologies should not only make it easy to find which tools are right for your organization, but which tools are in place today that should be the first to go. 

    In the end, all organizations have to face identity and access management challenges. Sometimes that’s a problem that can be tackled with a centralized solution from day one, but oftentimes it becomes a mess of tangled wires. Whether you’re starting from square one and building your technology set or you’re pulling those wires apart, the end goal of consolidated solutions is the best way to present a simple solution that makes your users happy while maintaining the security that your organization will depend on for years to come.

  • Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (more…)

  • In Building Communities, Our Preferred Pronoun is ‘We’

    In Building Communities, Our Preferred Pronoun is ‘We’

    It has been about 18 months since my last post. Toward the end of 2015 I started digging deeper into cybernetics and systems analysis, which led me to construct a model and write a paper. I haven’t posted it before now because it isn’t perfect. The funny thing is, I know it will never be perfect but I still have a list of edits to make. I always will.

    I would describe the paper as a form of hermeneutical phenomenology. The TL;DR on the model: it provides a basis to qualify systems for further analysis. Writing is a mechanism for me to study the model, but as my investigation varies so does my interpretation of what the paper should say. At the moment I’d like to add some observations around four-color mapping, thresholds and compactness. It’s a more rigorous argument than what I said about the continuum hypothesis, but I may leave that bit in anyway.

    Ultimately, the paper is my interpretation of the work I’ve studied. More than read my paper, I’d encourage anyone to review the sources themselves. It goes without saying that I couldn’t have written it in the first place if I weren’t standing on the shoulders of the giants that came before me.

    Self-Inflicted Othering

    I strongly identify as a technologist and a mathematician, but I would be neither of those things if it weren’t for the broader scientific community. Where I keep seeing people get stuck is celebrating our individual differences along with what we have in common. Humans have a tendency to form tribes and wage war. While I’m always glad to see the sense of belonging communities provide for their members, it’s the tendency to direct hostility toward other groups we should resist. J. Paul Reed wrote a post about this last year. We all have circles we run in where our faces are more familiar than others and it’s easy to get “othered” when we step outside of those environments.

    I meet a lot of really smart people at tech conferences who haven’t taken any trig or calculus. If I’m at a math conference I typically get a lot of beginner tech questions from people who are a different kind of brilliant. One conclusion from my paper is the operating environment is the ultimate constraint on a system. We can be local experts on whatever experience we have that’s not the focus of the event. We should also be able to find people that can teach us more about the event’s main topic while we’re there. If you find your experience in a field is making it difficult to learn, try spending more time with newer community members. Their challenges and experiences stand a good chance of providing a fresh perspective.

    We Rise

    This past week I spoke at We RISE Women in Tech Conference, which was hosted by Women Who Code Atlanta. I’ve been among the organizers for devopsdays Atlanta for the past two years and have been making an effort to engage the local community more.

    I spent most of my time at We RISE on the tools track. G. Ann Campbell gave a great talk on code quality called, “Refactoring with Cognitive Complexity: The New Option for Measuring Understandability.” I’ve used sonarqube for years and have been studying complexity science as part of my cybernetics journey. I felt like I was the target audience for her talk. I really liked Meera Subbarao’s talk, “Know Your Enemy, and Yourself: Demystifying Threat Modeling,” too. I enjoy any talk with maps and Sun Tzu quotes, but the highlights of Meera’s talk were the personal stories she shared about trust and failsafe experiments. Experimental methods are playing an increasingly important sociotechnical role in security as our systems become more complex and adaptive. I’m currently convinced all sociotechnical systems are cybernetic as a byproduct of their complexity and all cybernetic systems are sociotechnical at a coarse enough scale.

    Other Kinds of Othering

    It’s that kind of talk that got me grouped in with the “complexerati.” The first time I heard the word I knew they were talking about me (among others) and it wasn’t intended as a compliment. Nevertheless, I couldn’t deny it is who I am. I’ve also been called an insight junkie and street academic and I can’t deny those, either. I can get hooked on a phenomena and dig until I’m completely exhausted. I also never finished my undergraduate degree, which leaves me to perform my research in the street, like a busker. I’m not sure busting my chops over the part of my degree I’m missing is constructive feedback, but we can’t expect everyone to be nice to us all the time, either.

    I know we can catch people on a bad day so I try to be forgiving when someone gets a bit brisk with me. The complexerati comment led to some helpful advice after a diplomatic conversation. If I’m going to use language that’s specific but unconventional, I should make an effort to translate as I go along. People are comfortable with expanding their vocabulary but we shouldn’t introduce too much new material at once. What I said about cybernetics and sociotechnical systems translates into plainer English as, “any system with people in it is self-steering and any self-steering system will have people in it if we zoom out far enough.” The language isn’t quite as precise but it’s still accurate. Negative feedback can be helpful but we have to keep it constructive.fours

    Diplomatic Relations

    Churchill said, “Diplomacy is the art of telling people to go to hell in such a way that they ask for directions.” Communication is vital to trust and learning. Our human tendency to zoom in and steer toward our own familiar shores keeps us divided. This is an excerpt of my last post from December of 2015. It would seem my position has not changed.

    Instead of focusing on processes we should focus on enabling people to improve themselves. We improve when we learn and we learn when we communicate. If your culture does not foster communication can if foster learning? If you’re not open and honest with yourself, how does that effect your environment?

    I could go into more detail about my intentions for next year and may do so at a later date, but my plans are of no use to you as we are different people. I would encourage you to gain awareness of your own situation by challenging the assumptions that have bounded your operation.

    We can stay true to ourselves and our own identities while interacting with other communities. We’re members of some and just allies of others. It’s important to respect those boundaries and understand when our experience is welcomed and appreciated, when it’s time to listen and learn, and when it’s just not the time or place for us and we need to move onto something else for a while.

    We RISE was about technology and culture, which I believe are at the heart of what I’ve been studying for the past few years. The talks about DevOps and security couldn’t have been more relevant to my work. I felt some of the advice I heard in the keynotes from Jen Bonnett, Safia Abdalla and Estelle Weyl that was specifically targeted toward women was probably good advice for anyone, including me. Both Melanie Crissey and Sandra Persing shared their takeaways from the conference here and here, respectfully. Their posts should help shed some light on how I fit in and what I took away from this women’s tech conference more convincingly than I’ll be able to explain.

    I felt very welcomed and included at We RISE. Erica Stanley, Alicia Carr and Beth Laing threw a terrific event. We’re lucky to have them and Women Who Code as members of our Atlanta tech community.

    A Group Effort

    I think this slide I tweeted from Ashley Sun’s talk is the best I can do at summing it up. Ashley gave an awesome talk, during which she showed us how she’s using neo4j for cloud monitoring that gave developers in her organization the ability to manage more of their own infrastructure.

    Ashley shared Kelsey’s tweet in an effort to convince us that just because this solution was a good fit for her organization, it didn’t necessarily mean it would work for anyone else. Adrian Cockcroft had made the point that not everyone can be Netflix. Adrian used to work for them, so he might be a little biased. When Kelsey Hightower quoted him, it provided some external validation to the idea. Kelsey works for Google and they aren’t trying to be Netflix, either. They’re too busy being Google.

    Greg Poirier pointed out that not everyone can be Kelsey Hightower in his talk at devopsdays Silicon Valley a while back. I felt the point Adrian had about Netflix applies to us as individuals, too. Copying Kelsey’s results won’t give us the experience of walking Kelsey’s path. Some experience with Kubernetes may help you on your own journey, but it will never make you Kelsey Hightower. The same applies for Ashley Sun, Adrian Cockcroft and anyone who’s still reading this. We all have some experience others can learn from because we’re each on our own path. As things change over time and our memories fade, not all of what we remember remains how it was today. This is how the perspective of a novice can give fresh eyes to someone with more experience.

    One Step at a Time

    This is why Taiichi Ohno was unconcerned when people came from the United States and wanted to study TPS. By the time they had implemented what they had observed, the process at Toyota would have already adapted into something different (if you’d like to read more about it you should check out this book). The game we’re in has no finish line we can cross. The only successful move we can make is to try to support each other as individuals and communities as we’re able, sharing what we have in common.

    I had a great time at We RISE Women in Tech Conference and will look forward to it returning to Atlanta again next year.

    — Chris Corriere

  • 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