To adhere to the zero-trust principle of 'never trust, continuously verify,'
whether for the incorporation of dynamic attributes—such as Authorized time frame, Identity location, and Device compliance status—into authorization review conditions. This capability enables the dynamic revocation or restriction of access authorization and provides real-time alerts for abnormal situations.
Hi @Jameshclai, I'm not exactly sure what you're asking for here. I think it sounds like you're asking for enhancements to the policy system already in place, correct?
Assuming I have it right, it sounds like you're looking for location-based controls, time-based controls and additional controls from device posture.
These are requests that we are hearing more of lately, thank you for voicing your request. We definitely prioritize work based on real-world requests like this.
If interested, right now you can perform location-based controls by using an edge router which is on a separate network and restrict access to services via that edge router. We had a few users use this functionality in the past.
I would follow up with a request to be more prescriptive on the device posture compliance you would like to see @Jameshclai which is not already covered - Posture Checks | OpenZiti.
Also, do you have any examples of why you need this or is it just to comply with how other technology may implement aspects of zero trust principles. Any references to frameworks also appreciated.
OpenZiti authorization can be modified via API in near real time (or real time, depending on your definition) While the system does not do it itself it does allow for integration.
For example, if you are monitoring the traffic volume of the various services/identities via the utilization metrics provided by OpenZiti, and you have a machine learning algorithm or a full blown UEBA that can send an alert, it is reasonably easy to transform that alert into an action, e.g. revoking an identity's authorization for the service. This would result in the circuit being disconnected, stopping potential exfiltration of data.
Any endpoint monitoring system evaluating across whatever relevant criteria applies to the organization could do the same thing, send an alert to a SOC or other human operator for action, or have actions already provisioned and acted upon immediately.
So, while OpenZiti does not specifically provide these features, the robust information in the events and metrics and the API driven nature of the operations of the system make it easy to integrate the technology into the larger whole of an organization's information systems and their Zero Trust architecture.
1 Like
Thanks for your response. Since the ZTA solution is mandatory in Taiwan's public sector and finance, each ZTNA solution needs to comply with the NIST 800-207 standards and guidelines. The main criteria in Taiwan's government ZTA are "identity authentication," "device authentication," and "conditional authentication."
I understand that the Openziti Project uses PKI to fulfill identity authentication requirements. However, for device authentication, it needs to use a "Trusted Platform Module" to encrypt the identity key. For conditional authentication, all identities and devices must be continuously checked for security.
Can the Openziti Project meet these requirements?
@Jameshclai
Yes, our SDK and endpoints support TPM/HSM hardware keys via pkcs#11 standard
macOS/iOS: endpoints are using native platform keychain which means keys are secured by Secure Enclave on the device
windows: closer integration with Windows native keystore/TPM work is in progress
Linux: linux endpoint support using linux TPM device via TPM pkcs#11 driver
Android: endpoint use native Android keystore already - which mean keys are secured in hardware
Let us know if you have additional question or requirements
1 Like