When most enterprise users hear that their organization will start heavily using ServiceNow governance, they assume that their job is about to get much harder, not easier. This stems from admins putting overly-restrictive policies in place, even with the good intentions of preventing security or financial problems. The negative side effect of this often manifests itself as a huge limitation for users who are just trying to do their job. Ultimately, this can lead to “shadow IT”, angry users, and inefficient business processes. So how can you use ServiceNow governance to increase efficiency rather than prohibit it?
What is ServiceNow governance?
One of the main features of ServiceNow is the ability to implement processes for approvals, requests, and delegation. Governance in ServiceNow includes the policies and definitions of how decisions are made and who can make those decisions. For example, if a user needs a new virtual machine in AWS, they can be required to request one through the ServiceNow portal. Depending on the choices made during this request, cloud admins or finance team members can be alerted to this request and be asked to approve the request before it is carried out. Once approved, the VM will have specific tags and configuration options that match compliance and risk profiles.
What Drives Governance?
Governance policies are implemented with some presumably well-intentioned business goal in mind. Some organizations are trying to keep risk managed through approvals and visibility. Others are trying to rein in IT spending by guiding users to lower-cost alternatives to what they were requesting.
Too often, to the end user, the goal gets lost behind the frustration of actions being slowed, blocked, or redirected by the (beautifully automated) red tape. Admins lose sight of the central business needs while implementing a governance structure that is trying to protect those business needs. For users to comply with these policies, it’s crucial that they understand the motivations behind them – so they don’t work around them.
In practice, this turns into a balancing act. The guiding question that needs to be answered by ServiceNow governance is, “How can we enable our users to do their jobs while preventing costly (or risky) behavior?”
Additionally, it’s critical that new policies are clearly communicated, and that they hook into existing processes. Not to say that this is easy. To be done well, it requires a team of technical and business stakeholders to provide their needs and perspectives. Knowing the technical possibilities and limitations must match up with the business needs and overall organizational plans, while avoiding roadblocks and managing edge cases. There’s a lot to mesh together, and each organization has unique challenges and desires, which makes this whole process hard to generalize.
The End Result
At ParkMyCloud, we try to help facilitate these kinds of governance frameworks. The ParkMyCloud application allows admins to set permissions on users and give access to teams. By reading from resource tags, existing processes for tagging and naming can be utilized. New processes around resource schedule management can be easily communicated via chat or email notifications. Users get the access they need to keep doing their job, but don’t get more access than required. Employing similar ideas in your ServiceNow governance policies can make your users successful and your admins happy.
Google Cloud IAM (Identity and Access Management) is the core component of Google Cloud that keeps you secure. By adopting the “principle of least privilege” methodology, you can work towards having your infrastructure be only accessible by those who need it. As your organization grows in size, the idea of keeping your IAM permissions correct can seem daunting, so here’s a checklist of what you should think about prior to changing permissions. This can also help you as you continuously enforce your access management.
1. Who? (The “Identity”)
Narrowing down the person or thing who will be accessing resources is the first step in granting IAM permissions. This can be one of several options, including:
- A Google account (usually used by a human)
- A service account (usually used by a script/tool)
- A Google group
- A G-Suite domain
Our biggest recommendation for this step is to keep this limited to as few identities as possible. While you may need to assign permissions to a larger group, it’s much safer to start with a smaller subset and add permissions as necessary over time. Consider whether this is an automated task or a real person using the access as well, since service accounts with distinct uses makes it easier to track and limit those accounts.
2. What Access? (The “Role”)
Google Cloud permissions often correspond directly with a specific Google Cloud REST API method. These permissions are named based on the GCP service, the specific resource, and the verb that is being allowed. For example, ParkMyCloud requires a permission named “compute.instances.start” in order to issue a start command to Google Compute Engine instances.
These permissions are not granted directly, but instead are included in a role that gets assigned to the identity you’ve chosen. There are three different types of roles:
- Primitive Roles – These specific roles (Owner, Editor, and Viewer) include a huge amount of permissions across all GCP services, and should be avoided in favor of more specific roles based on need.
- Predefined Roles – Google provides many roles that describe a collection of permissions for a specific service, like “roles/cloudsql.client” (which includes the permissions “cloudsql.instances.connect” and “cloudsql.instances.get”). Some roles are broad, while others are limited.
- Custom Roles – If a predefined role doesn’t exist that matches what you need, you can create a custom role that includes a list of specific permissions.
Our recommendation for this step is to use a predefined role where possible, but don’t hesitate to use a custom role. The ParkMyCloud setup has a custom role that specifically lists the exact REST API commands that are used by the system. This ensures that there are no possible ways for our platform to do anything that you don’t intend. When following the “least privilege” methodology, you will find that custom roles are often used.
3. Which Item? (The “Resource”)
Once you’ve decided on the identity and the permissions, you’ll need to assign those permissions to a resource using a Cloud IAM policy. A resource can be very granular or very broad, including things like:
- GCP Projects
- Single Compute Engine instances
- Cloud Storage buckets
Each predefined role has a “lowest level” of resource that can be set. For example, the “App Engine Admin” role must be set at the project level, but the “Compute Load Balancer Admin” can be set at the compute instance level. You can always go higher up the resource hierarchy than the minimum. In the hierarchy, you have individual service resources, which all belong to a project, which can either be a part of a folder (in an organization) or directly a part of the organization.
Our recommendation, as with the Identity question, is to limit this to as few resources as possible. In practice, this might mean making a separate project to group together resources so you can assign a project-level role to an identity. Alternatively, you can just select a few resources within a project, or even an individual resource if possible.
And That’s All That IAM
These three questions provide the crucial decisions that you must make regarding Google Cloud IAM assignments. By thinking through these items, you can ensure that security is higher and risks are lower. For an example of how ParkMyCloud recommends a custom role assigned to a new service account in order to schedule and resize your VMs and databases, check out the documentation for ParkMyCloud GCP access, and sign up for a free trial today to get it connected securely to your environment.
Microsoft Azure IAM, also known as Access Control (IAM), is the product provided in Azure for RBAC and governance of users and roles. Identity management is a crucial part of cloud operations due to security risks that can come from misapplied permissions. Whenever you have a new identity (a user, group, or service principal) or a new resource (such as a virtual machine, database, or storage blob), you should provide proper access with as limited of a scope as possible. Here are some of the questions you should ask yourself to maintain maximum security:
1. Who needs access?
Granting access to an identity includes both human users and programmatic access from applications and scripts. If you are utilizing Azure Active Directory, then you likely want to use those managed identities for role assignments. Consider using an existing group of users or making a new group to apply similar permissions across a set of users, as you can then remove a user from that group in the future to revoke those permissions.
Programmatic access is typically granted through Azure service principals. Since it’s not a user logging in, the application or script will use the App Registration credentials to connect and run any commands. As an example, ParkMyCloud uses a service principal to get a list of managed resources, start them, stop them, and resize them.
2. What role do they need?
Azure IAM uses roles to give specific permissions to identities. Azure has a number of built-in roles based on a few common functions:
- Owner – Full management access, including granting access to others
- Contributor – Management access to perform all actions except granting access to others
- User Access Administrator – Specific access to grant access to others
- Reader – View-only access
These built-in roles can be more specific, such as “Virtual Machine Contributor” or “Log Analytics Reader”. However, even with these specific pre-defined roles, the principle of least privilege shows that you’re almost always giving more access than is truly needed.
For even more granular permissions, you can create Azure custom roles and list specific commands that can be run. As an example, ParkMyCloud recommends creating a custom role to list the specific commands that are available as features. This ensures that you start with too few permissions, and slowly build up based on the needs of the user or service account. Not only can this prevent data leaks or data theft, but it can also protect against attacks like malware, former employee revenge, and rogue bitcoin mining.
3. Where do they need access?
The final piece of an Azure IAM permission set is deciding the specific resource that the identity should be able to access. This should be at the most granular level possible to maintain maximum security. For example, a Cloud Operations Manager may need access at the management group or subscription level, while a SQL Server utility may just need access to specific database resources. When creating or assigning the role, this is typically referred to as the “scope” in Azure.
Our suggestion for the scope of a role is to always think twice before using the subscription or management group as a scope. The scale of your subscription is going to come into consideration, as organizations with many smaller subscriptions that have very focused purposes may be able to use the subscription-level scope more frequently. On the flip side, some companies have broader subscriptions, then use resource groups or tags to limit access, which means the scope is often smaller than a whole subscription.
More Secure, Less Worry
By revisiting these questions for each new resource or new identity that is created, you can quickly develop habits to maintain a high level of security using Azure IAM. For a real-world look at how we suggest setting up a service principal with a custom role to manage the power scheduling and rightsizing of your VMs, scale sets, and AKS clusters, check out the documentation for ParkMyCloud Azure access, and sign up for a free trial today to get it connected securely to your environment.
Taking your organization into a full multi-cloud deployment can be a daunting task, but focusing on adopting just an AWS multi-account strategy can provide many benefits without a lot of extra effort. AWS makes it quite easy to create new accounts on a whim, and can simplify things with consolidated billing. Let’s take a look at why you might want to split your monolithic AWS account into micro accounts.
1. Logical Separation of Resources
There are a few options for separating your resources within a single AWS account, including tagging, isolated VPCs, or using different regions for different groups. However, these practices can still lead to extensive lists of resources within your account, making it hard to find what you need. By creating a new account for each project, business unit, or development stage, you can enforce a much better logical separation of your resources. You can still use separate VPCs or regions within an account, but you aren’t forced to do so.
2. Security and Governance
In addition to separation for logical purposes, multiple accounts can also help from a security perspective. For example, having a “production” account separate from a “development” account lets you give broader access to your developers and operations teams based on which account they need access to. AWS provides a great “IAM Analyzer” tool that can help you ensure proper security and roles for your users. And if you have ever had a developer hard-code account access information, separated accounts can help bring that to light (we have not this happen at ParkMyCloud, but we have definitely seen it a couple of times over the years…).
3. Cost Allocation
In addition to tagging your systems for cost reporting, separation into different accounts can help with the chargeback and showback to your business units. Knowing which accounts are spending too much money can help you tweak your processes and find cloud waste. The AWS Cost and Usage Reports show exactly which account is associated with each expense.
4. Cost Savings Automation
You can apply cost savings automation at a granular level – but it’s easier if you don’t have to. For example, you should enforce schedules to automatically turn off resources outside of business hours. Some of our customers are eager to add their development-focused account to ParkMyCloud to allow for scheduling automation, but are a bit leery of adding Production accounts where someone might turn something off by accident. Automated scripts and platforms such as ParkMyCloud can be fully adopted on dev and sandbox accounts to streamline your continuous cost control, while automation around your production environment can be used to make sure everything is up and running. AWS IAM policies can also allow you to set different policies on different accounts, for example, allowing scheduling and rightsizing automation in dev/test accounts, but only manual rightsizing in production.
5. Reserved Instances and Savings Plans
In an AWS environment where you have multiple accounts all rolling up to an Organization account, Reserved Instances and Savings Plans can be shared across all the associated accounts. Say you buy an RI or Savings plan in one account, but then end up not fully using it in that account. AWS will automatically allocate that RI to any other account in the Organization that has the right kind of system running at the right time. A couple of our larger customers with really mature cloud management practices take this a step further and carefully manage all RI purchases using a dedicated “cloud management” account within the Organization. This allows them to maintain a portfolio of RIs and Savings Plans (kind of like a stock market portfolio) designed to optimize spend across the entire company, and limiting commitments to RIs that might not be needed due to idle RI’s purchased by some other group on some other account. This allows them to smooth out the purchase of expensive multi-year and all-upfront RIs and Savings Plans over the course of time.
6. Keeping Your Options Open
Even if you aren’t multi-cloud at the moment, you never know how your cloud strategy might evolve over the next few years. By separating into multiple AWS accounts, it helps you keep your options available for individual groups or applications to move to different cloud providers without disrupting other departments. This flexibility can also help your management feel at ease with choosing AWS, as they won’t feel as locked-in as they otherwise might.
Get Started With An AWS Multi-Account Strategy
If you haven’t already started using multiple AWS accounts, Amazon provides a few different resources to help. One recent announcement was AWS Control Tower, which helps with the deployment of new accounts in an automated and repeatable fashion. This is a step beyond the AWS Landing Zone solution, which was provided by Amazon as an infrastructure-as-code deployment. Once you have more than one account, you’ll want to look into AWS Organizations to help with management and grouping of accounts and sharing reservations.
For maximum cost savings and cloud waste reduction, use ParkMyCloud to find and eliminate cloud waste – it’s fully multi-account aware, allowing you to see all of your accounts in a single pane of glass. Give it a try today and get recommended parking schedules across all of your AWS accounts.
Do you know the difference between Azure “deallocate VM” and “stop VM” states? They are similar enough that in conversation, I’ve noticed some confusion around this distinction.
If your VM is not running, it will have one of two states – Stopped, or Stopped (deallocated). Essentially, if something is “allocated” – you’re still paying for it. So while deallocating a virtual machine sounds like a harsh action that may be permanently deleting data, it’s the way you can save money on your infrastructure costs and eliminate wasted Azure spend with no data loss.
Azure’s Stopped State
When you are logged in to the operating system of an Azure VM, you can issue a command to shut down the server. This will kick you out of the OS and stop all processes, but will maintain the allocated hardware (including the IP addresses currently assigned). If you find the VM in the Azure console, you’ll see the state listed as “Stopped”. The biggest thing you need to know about this state is that you are still being charged by the hour for this instance.
Azure’s Deallocated State
The other way to stop your virtual machine is through Azure itself, whether that’s through the console, Powershell, or the Azure CLI. When you stop a VM through Azure, rather than through the OS, it goes into a “Stopped (deallocated)” state. This means that any non-static public IPs will be released, but you’ll also stop paying for the VM’s compute costs. This is a great way to save money on your Azure costs when you don’t need those VMs running, and is the state that ParkMyCloud puts your VMs in when they are parked.
Which State to Choose?
The only scenario in which you should ever choose the stopped state instead of the deallocated state for a VM in Azure is if you are only briefly stopping the server and would like to keep the dynamic IP address for your testing. If that doesn’t perfectly describe your use case, or you don’t have an opinion one way or the other, then you’ll want to deallocate instead so you aren’t being charged for the VM.
If you’re looking to automate scheduling when you deallocate VMs in Azure, ParkMyCloud can help with that. ParkMyCloud makes it easy to identify idle resources using Azure Metrics and to automatically schedule your non-production servers to turn off when they are idle, such as overnight or on weekends. Try it for free today to save money on your Azure bill!