{"id":46176,"date":"2022-04-13T00:00:00","date_gmt":"2022-04-13T00:00:00","guid":{"rendered":"urn:uuid:c3e85aae-1d7e-045e-3357-3b28face5e72"},"modified":"2022-04-13T00:00:00","modified_gmt":"2022-04-13T00:00:00","slug":"cybersecurity-basics-authentication-and-authorization","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/cybersecurity-basics-authentication-and-authorization\/","title":{"rendered":"Cybersecurity Basics: Authentication and Authorization"},"content":{"rendered":"

<\/p>\n

<\/div>\n

What is identity and access management?<\/span><\/p>\n

Identity and access management (IAM) ensures the right people in the right job roles can access the tools, systems, and services absolutely necessary to do their jobs. It is part of the foundation to a strong zero trust approach<\/a> that answers two fundamental questions you should be asking about every solution you build: who is that and what have we allowed them to do?<\/p>\n

The \u201cWho\u201d<\/span><\/p>\n

Determining who you are is called \u201cauthentication<\/a>.\u201d<\/p>\n

This is a process that we encounter all the time. Every time we log in, we\u2019re authenticating to a system.<\/p>\n

Usually, we do this with a unique username and password. To provide additional security and assurances, multi-factor authentication is highly recommended.<\/p>\n

Multi-factor<\/a> or two factor authentication is when\u2014in addition to a username and password\u2014the user requires another way of identifying themselves. This often generates a one-time code for a smartphone app or via text message.<\/p>\n

The security concept behind this approach is simple. Now to get into an account you must:<\/p>\n

    \n
  1. Know the username<\/li>\n
  2. Know the password<\/li>\n
  3. Have access to the device with the one-time code at the same time<\/li>\n<\/ol>\n

    Honestly, the username is typically public knowledge. It\u2019s often someone\u2019s email or a public displayed. That leaves something you know (the password) and something you have (the device with the one-time code).<\/p>\n

    While you can add more ways of verification, like something you are (biometrics) but this approach<\/a> often strikes the right balance of usable with a good set of security practices.<\/p>\n

    Building The \u201cWho\u201d<\/span><\/p>\n

    When you are building in the cloud, you\u2019ll deal with this concept in two ways.<\/p>\n

    The first is proving to your cloud service provider that you are who you say you are.<\/p>\n

    For your cloud accounts, there is a strong recommendation to use multi-factor authentication. This will help to ensure that only valid users have access to you cloud resources.<\/p>\n

    The second way you\u2019ll deal with authentication is when you\u2019re building a way for users of your solution to login. Thankfully, a lot of the heavy lifting has already been done for you.<\/p>\n

    Each of the major cloud providers has a host of options for user authentication. This includes single sign-on<\/a> systems that will help leverage the accounts and identities you may already have access to.<\/p>\n

    What Are They Allowed To Do?<\/span><\/p>\n

    Now that you know who is making a request, the next question is \u201cWhat are they allowed to do?\u201d<\/p>\n

    This is called authorization<\/a>.<\/p>\n

    Usually, authorization expresses permissions and rights granted to a user. The single, most important concept to apply here is called the principle of least privilege<\/a>.<\/p>\n

    This is the idea that you should only grant a user the permissions they require to do the task at hand and no more<\/b>.<\/p>\n

    Yes, it\u2019s just easier to give everyone administrator rights. You probably are using administrator rights on at least one system you don\u2019t have to right now.<\/p>\n

    But this approach leads to a lot of security and privacy issues that you do not want to have to deal with. Using the principle of least privilege is a much more effective approach that leads to resilient and reliable systems.<\/p>\n

    The good news? Each of the big three cloud service providers have a \u201cdefault deny\u201d environment in place.<\/p>\n

    This means that by default<\/b> users (and other entities) can\u2019t do anything.<\/p>\n

    You need to explicitly grant permissions. This makes it a lot easier to follow the principle of least privilege.<\/p>\n

    Managing The What<\/span><\/p>\n

    As your environment grows, managing permissions can become a full-time job. No one wants that.<\/p>\n

    You can apply permissions to users, roles, or other resources directly. Additionally, you can group them together in a policy and apply those policies to users, roles, and resources.<\/p>\n

    Using policies is definitely the way to go.<\/p>\n

    While it\u2019s tempting to just assign a required permission to the user or resource that needs them, that\u2019s a recipe for a disaster.<\/p>\n

    Imagine that you have three people on the team who are working on a database. One of them is pushing out the latest update for your solution and runs into a permissions problem.<\/p>\n

    The solution? They need an additional permission to the database.<\/p>\n

    Now you could assign that directly to that team member\u2019s account but what about the other two people who work on the database? They will need this permission as well.<\/p>\n

    This is where a policy comes into play. Assigning the permissions to the policy and that policy to anyone who needs to accomplish that task is much more efficient.<\/p>\n

    In this example, we should assign all three team members the \u201cDatabase workers\u201d policy and that policy assigns the required permissions. Any changes in the permissions will update the policy. This automatically grants the permissions to the three team members assigned to that policy.<\/p>\n

    This extra abstraction makes managing permissions a lot easier\u2026and yes, users and resources can have more than one policy applied.<\/p>\n

    What\u2019s Next?<\/span><\/p>\n

    There are other move advanced concepts around authentication (who you are) and authorization (what you are allowed to do) but this post covers the foundations.<\/p>\n

    Remember two critical takeaways;<\/p>\n