TechBytes: Vantage - Secure Zones

Once upon a time there was a king looking for a safe place for his people, on a wonderful hilltop, far away from the crowds, that allowed him to rule his people and manage his property completely independent. Fast forward now 1000 years. Are you thinking about getting your own database for your use case? Because you have regulatory requirements to protect your data, or they are asking for independent management of the environment? Are you prepared to build out a separate system, implement redundant infrastructure, and then drag all your data and users into the new remote place? What if you could use some space close to the rest of the community that allows you to leverage all shared infrastructure, and it gives you the independence and protection you are looking for? What if you could use some space close to the rest of the community that allows you to leverage all shared infrastructure, and it gives you the independence and protection you are looking for? That’s what Secure Zones can do for you. Secure zones provide a virtual database environment that isolates data and users including its administration. Until recently customers had to buy multiple systems if regulations required the complete separation of business units. With Secure Zones customers have now the option to have data and users coexist on a shared platform that otherwise might have to fund their own system. It also streamlines the administration by pushing functions into the teams. By introducing the concept of zones there is an easier identification of the private zones, and simplified security administration. For zone users it looks like they are on their own system, completely shielding them from other work being done on the platform. It improves the total cost of ownership by co–hosting otherwise separated applications while still satisfying security concerns and leveraging a larger resource pool. It enables customers to co–host applications that must be strictly separated from others in a private cloud sharing their Teradata resources. This is the first release of Secure Zones and some limitations exist. All object names must be unique across the system including objects in zones. This includes objects like DATABASE, USER, ROLE, PROFILE, CONSTRAINT, AUTHORIZATION, and FOREIGN SERVER. Naming conventions that are aware of Zones overcome this limitation. Also zones can not be nested – So a zone can not contain another zone. What are Zones on Teradata? Starting out on a normal Teradata system with it’s system level administrators and users, as well as system meta data and the dictionary, and production data, you can define databases as secure zones with its own administrators, it’s own users and it’s own data. Once secure zones are setup they can act and work independently from each other, everyone only seeing their part of the platform. Let’s peel the onion and look what happens on the system when setting up a secure zone. Before you create a zone, your system DBA’s might want to create a dedicated ZoneAdmin user with the CREATE ZONE privilege along with a database MyZones that serves as a parent for all zones to be created. The Zone Admin will be used from now on to manage all zones on the system. In our example he can create a Zone Z1 with its root Z1_ROOT. If Z1_ROOT is a user (vs. database) it automatically becomes the zone’s primary DBA. If it is a database, like in this case and recommended best practice, the zone’s primary DBA can be created as Z1_DBA. All privileges will be granted implicitly on the DBA user. He can create objects in the zone, but can not execute any DML statements on objects not in his space. This DBA acts like a DBC user within its zone. He can create users, databases, tables, roles, and grant privileges within it’s zone. According to the setup by the DBA, zone users can then create or access objects within their zone, and only within their zone, according to the discretionary access rights granted to them. They can never access any objects in other zones. However it can be setup that zone users get access to non–zoned data including dictionary. A user on a system level can be allowed as a guest to a zone. This is a 2 step process: the user must be granted the ZONE access by a system level administrator and having all discretionary rights granted by the ZONE DBA; To ensure the isolation of a zone, zone access can’t be granted to DBC, the zone creator, any roles granted to the zone creator, or zone users or roles of other zones. Here is a quick overview over some new DDL and DCL commands used in the previous example. CREATE ZONE is a new privilege that has to be granted to system level zone administrators before they even can create new zones. CREATE ZONE will create a new zone and define it’s root database or user. A ZONE DBA can be created by adding the keyword DBA. And finally the administrator can allow access to guest users by granting them access to the ZONE; note that discrete access rights are still required to see any data within the zone. Obviously there are additional new statements available to revoke access, or alter and drop zones, not shown here. Obviously there are additional new statements available to revoke access, or alter and drop zones, not shown here. Now let’s look at 3 use cases where Secure Zones apply. Here we have an international company or conglomerate where access to subsidiary data must be tightly controlled and restricted to users of the subsidiary or citizens of a specific country. The way you would set it up is to have the system level zone administrator define a zone for each country, and have all users and objects defined in their respective zones. This will prevent them from seeing anything outside their zone. Corporate users with GUEST privileges can access data in those zones, can even join tables from various zones in a single SQL statement. The administration of all zone related topics will be delegated to the country organization. Also interesting to note is the fact that data in system tables that have been extended for zones, like DBQL, only allow users to see information about their respective zones. Zone users can never see anything outside their zone. System level users will see non–zoned information but can be granted the ZONE OVERRIDE privilege if they need unrestricted access on those tables. In a multi–tenancy environment, multiple tenants may be consolidated onto one instance of a database system while isolating the tenants from each other as if they were running on physically segregated databases. This case is very similar to the first one, the conglomerate. Each tenant perceives their zone as if it would be their own Teradata system. All administration will be done by the Zone DBA. The major difference is the lack of system level users requiring access to zones of tenants. Here we have independent tenants and there is no need for overarching activities by central business functions. For this use case it might be a good idea to completely restrict access to non–zone data to any zone users. This can be accomplished by setting the new DBS control flag (internal 365). And finally, creation of a “sandbox” environment within a production database for experimentation, modeling or prototyping. In this case all users would be defined on the system level only and granted guest privilege to their respective zones. They still have access to all system level data as before, and can create new tables and views in the sandbox space. However, they can not grant access to other unauthorized users or roles. Those users must be explicitly granted zone access by the zone DBA first.Once upon a time there was a king looking for a safe place for his people, on a wonderful hilltop, far away from the crowds, that allowed him to rule his people and manage his property completely independent. Fast forward now 1000 years. Are you thinking about getting your own database for your use case? Because you have regulatory requirements to protect your data, or they are asking for independent management of the environment? Are you prepared to build out a separate system, implement redundant infrastructure, and then drag all your data and users into the new remote place? What if you could use some space close to the rest of the community that allows you to leverage all shared infrastructure, and it gives you the independence and protection you are looking for? What if you could use some space close to the rest of the community that allows you to leverage all shared infrastructure, and it gives you the independence and protection you are looking for? That’s what Secure Zones can do for you. Secure zones provide a virtual database environment that isolates data and users including its administration. Until recently customers had to buy multiple systems if regulations required the complete separation of business units. With Secure Zones customers have now the option to have data and users coexist on a shared platform that otherwise might have to fund their own system. It also streamlines the administration by pushing functions into the teams. By introducing the concept of zones there is an easier identification of the private zones, and simplified security administration. For zone users it looks like they are on their own system, completely shielding them from other work being done on the platform. It improves the total cost of ownership by co–hosting otherwise separated applications while still satisfying security concerns and leveraging a larger resource pool. It enables customers to co–host applications that must be strictly separated from others in a private cloud sharing their Teradata resources.