These tiers are useful for coarse grain access control of client devices, which we have found to be sufficient in most cases. The basic concept of tiers is relatively straightforward: access to data increases as the device security hardening increases. The troubleshooting section below provides additional techniques to help minimize the impact of misconfigured trust logic. It’s wise to add alarms if the system starts dropping (or raising) the trust of too many machines at once. A bug in your trust evaluation system could cause it to start mis-evaluating trust.
You must have the ability to adequately test policy changes to mitigate the blast radius from these types of bugs, and ideally canary changes to subsets of the fleet for a baking period. If there are bugs in the trust definitions or evaluations themselves, this can also quickly remove trust from ‘good’ devices. We should note that the system’s ability to quickly remove trust from devices can be a double edged sword. Changes to device posture can similarly immediately impact trust. Changes to trust definitions can be immediately reflected across the entire fleet. This means you can evaluate trust as often as you feel necessary. The frequency of device trust evaluation is independent from certificate issuance in a tiered access setup. Below are three ways in which tiered access helps address these concerns.
Moving the trust evaluation out-of-band from the certificate issuance allows us to circumvent the challenges identified above in the traditional system. Trust decisions are then made by a separate system which can be modified without interfering with the certificate issuance process or validity.
In this new model, certificates are simply used to provide the device’s identity, instead of acting as proof of trust. Tiered access attempts to address all these challenges, which is why we decided to adopt it. Additionally, if a device is found to be out of compliance with security policy, the only option is to remove all access by revoking the certificate, rather than degrading access, which can create a frustrating all-or-nothing situation for the user. On the other hand, if you require certificates to be installed monthly or daily, you have placed a significant burden on your users and/or support staff, as they are forced to go through the certification issuance process far more often, which can be time consuming and frustrating. Therefore, any new requirements you wish to add to the fleet may take up to a year before they are fully in effect.
GOOGLE BEYONDCORP DIAGRAM INSTALL
If you only install a new certificate once a year, this means it might take an entire year before you are able to recertify a device. The most significant challenge is the large amount of time in between trust evaluations. This implies you must have an additional infrastructure to bootstrap a device into a trusted state. This sounds reasonable on paper, but it unfortunately means that existing certificate infrastructure can’t be used to aid device provisioning. The next challenge introduced by traditional systems is the inherent requirement that a device must meet your security requirements before it can get a certificate. a dashboard displayed in a public space). corporate financials) or far less sensitive data (e.g. These systems tend to evaluate a device based on a single set of criteria, regardless of whether devices require access to highly sensitive data (e.g.These systems don’t easily allow for nuanced access based on shifting security posture.non-standard issue devices, older platforms required for testing, BYOD, etc.). Not all devices need the same level of security hardening (e.g.However, there are a number of challenges with this setup: It’s typically a lightweight process and many off-the-shelf products exist to implement flows that adhere to this principle. At predefined intervals, clients prove they can be trusted and a new certificate is issued. With such a system, any device with a valid certificate can be trusted. Google used this approach initially as it dramatically simplified device trust.
In a traditional client certificate system, certificates are only given to trusted devices.
0 kommentar(er)
