## E4B3

### Tech and Architecture

* E4B3 uses products from IBM, Mandiant, Palo Alto Networks, Tenable, and VMware. Certificates from DigiCert are also used.

* Table L-1 lists all of the technologies used in E4B3 ZTA. It lists the products used to instantiate each ZTA 4839 component and the security function that each component provides.


* 圖L-1描述了E4B3的邏輯架構。圖L-1使用編號箭頭來描述主體請求訪問資源所需的消息的一般流程，並根據主體身份（包括請求用戶和請求端點身份）、授權和請求端點健康來評估該訪問請求。

* 此外，它描述了支援定期重新驗證請求用戶和請求端點，以及定期驗證請求端點健康狀態的消息流程。所有這些都必須進行，以持續重新評估訪問權限。圖L-1中標記的步驟具有與圖4-1相同的含義。然而，圖L-1還包括實例化E4B3架構的具體產品。圖L-1還不顯示在圖4-1中找到的任何資源管理步驟，因為在E4B3中部署的ZTA技術不支持對資源執行身份驗證和重新驗證，或者對資源健康進行定期驗證。

* E4B3 was designed with IBM Security Verify as the ZTA PE, PA, and PEP, and IBM Security Verify providing ICAM support.


* Enterprise 4 Physical Architechture (E4B3)


### Message Flows for Successful Resource Access Requests

* This section depicts some high-level message flows for E4B3 supporting the use case in which a subject who has an enterprise ID and who is authorized to access an enterprise resource requests and receives access to that resource.

* In the first use case, the access request is coming from a managed device, and in the second use case, the access request is coming from an unmanaged device.

#### Use Case in which the Requesting Endpoint is Managed

* In this use case, the requesting endpoint is managed by IBM MaaS360. MaaS360 is a UEM that consists of an agent on the endpoint and a cloud component that work together to perform device authentication.


The message flow depicted in Figure L-2 consists of the following steps:
1. A user requests to access a resource from a managed endpoint.
2. The resource receives the access request and sends a user authentication request to IBM Security Verify/Trusteer.
3. Certificate authentication is initiated with the MaaS360 agent.
4. IBM Security Verify/Trusteer authenticates the requesting device’s certificate.
5. Verify/Trusteer checks the endpoint’s compliance status based on information shared by MaaS360.
6. Verify/Trusteer evaluates the access policy rules to determine if the access request is authorized.
7. Assuming the request is authorized and the endpoint has passed the authentication and authorization checks, IBM Security Verify/Trusteer creates a SAML assertion token and sends it to the resource. The resource accepts the assertion and grants the access request.
8. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).

#### Use Case in which the Requesting Endpoint Is Unmanaged

* In this use case, the requesting endpoint is unmanaged. There is no endpoint agent running on the device, so device compliance cannot be enforced.


The message flow depicted in Figure L-3 consists of the following steps:
1. A user requests to access a resource from an unmanaged endpoint.
2. The resource receives the access request and sends a user authentication request to IBM Security Verify/Trusteer.
3. The user is prompted to provide username and password.
4. IBM Security Verify/Trusteer verifies the username and password.
5. Verify/Trusteer evaluates the access policy rules to determine if the access request is authorized.Requesting endpoint ZTA ComponentsIBM Security Verify/Trusteer Subject ResourceUser
6. Verify/Trusteer creates a SAML assertion token and sends it to the resource. The resource accepts theassertion and grants the access request
7. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).

* Note that the message flows depicted in both of these use cases applies to several of the other use cases we are considering. It applies to all cases in which a user with an enterprise ID who can successfully authenticate themselves requests and receives access to an enterprise resource that they are authorized to access.

**Conclusion:**

E4B3中部署的ZTA技術不支援對資源進行身份驗證和重新身份驗證，以及對資源健康進行定期驗證的能力。這是他與其他架構最不同的地方。至於實作方面，在裝置有被管理的情況下，我們的Authentication是由 IBM MaaS360 負責，由裝置上的Agent與雲上的服務去做驗證，驗證完成後須做存取(Access)，而Access的管理是由 IBM Security Verify(IBM Security Verify/Trusteer)負責，而 IBM Security Verify 會驗證裝置的合法性並檢查它的存取權限，若這些關卡都通過了，EndPoints才能正常存取資源(Resource)。若是在裝置沒有被管理的情況下，則Authentication也是由 IBM Security Verify 負責，這時要驗證的就是User的帳號密碼了，若驗證通過才會進到Access驗證的階段。並且作者說明希望這個Message Flow可以適用在任何的use case，不論subject及resource的位置，Message Flow都能一致的運作。