Unified Authentication and Role Management
Allows our customers to easily integrate their existing Kerberos, LDAP, and Active Directory users and schemes across the DataStax Enterprise product suite.
DataStax Enterprise (DSE) Advanced Security plays a critical role in keeping our customers’ data safe. Enterprise companies have very strict security requirements, which is why DSE Advanced Security provides robust and easy-to-use security functionality, including: Unified Authentication and Role Management – Allows our customers to easily integrate their existing Kerberos, LDAP, and Active Directory users and schemes across the DataStax Enterprise product suite. Data Auditing – Gives administrators the ability to understand “who looked at what, when” and “who changed what, when”, which is crucial for meeting many security compliance standards. Row Level Access Control and Proxy Authentication – Restricts which rows a user has access to within a table while preserving client-side identities and privileges in middleware such as web servers. Today, we’re excited to announce three new critical security enhancements available in DSE 6: Private Schemas, Auditing by Role, and Separation of Duties. Private Schemas We’re now giving administrators more control over schema visibility. Administrators can control whether or not a user can see certain schema definitions, which can be especially helpful in securing multi-tenant applications. Private Schemas supports the principle of least privileges, which is key for meeting many security compliance standards. Auditing by Role We’ve enhanced auditing with the ability to audit changes and user activity by role. Traditionally, auditing in DSE was controlled by which respective database object you wanted to keep track of. Having role-based auditing greatly reduces the audit trail, since most administrators want to keep track of human activity rather than machine-generated activity. Auditing by role is as simple as either including or excluding roles from the dse.yaml. Separation of Duties There are many cases where administrators need full control of the database but should not have access or visibility to the data itself. For example, imagine a doctor or nurse who requires access to sensitive medical data. In this case, the administrator would still have the correct privileges to grant access to the doctor or nurse but the administrator would not be able to access the data. Restricting SELECT and MODIFY privileges on an admin role is simple in CQL. Now’s Your Chance for Total Security Security continues to be a priority in DSE, and we’re excited for you to try the new security enhancements in DSE 6. For more information on how how to implement these new security enhancements or any of the DataStax Enterprise Advanced Security components, or to download DSE 6, please visit: DataStax Academy DataStax Docs
DataStax Enterprise 6.7 delivers the leading distribution of Apache Cassandra with multi-workload support for operational analytics, geospatial search, increased data protection in the cloud, better performance insights, Docker production support, and connectivity to Apache Kafka™. Listen to this podcast to learn more!
There are many cases where administrators need full control of the database but should not have access or visibility to the data itself. For example, imagine a doctor or nurse who requires access to sensitive medical data. In this case, the administrator would still have the correct privileges to grant access to the doctor or nurse but the administrator would not be able to access the data.
Traditionally, auditing in DSE was controlled by which respective database object you wanted to keep track of. Having role-based auditing greatly reduces the audit trail, since most administrators want to keep track of human activity rather than machine-generated activity.
Allows our customers to easily integrate their existing Kerberos, LDAP, and Active Directory users and schemes across the DataStax Enterprise product suite.
Gives administrators the ability to understand “who looked at what, when” and “who changed what, when”, which is crucial for meeting many security compliance standards.
Restricts which rows a user has access to within a table while preserving client-side identities and privileges in middleware such as web servers.
Use GRANT/REVOKE paradigm and Active Directory/LDAP to assign access permissions.
Securing your data should be top of mind for any modern application. Security breaches are on the rise and the associated penalties are severe, impacting your brand and, in turn, your customer loyalty and trust. Consider the following security practices to protect your data and the distributed system that manages it. These practices apply to distributed system architectures that could include intercloud, hybrid, and/or multi-cloud. They can also be applied to systems with specialized compliance requirements in regulated environments; financial services; payments; health systems/HIPAA in the United States and GDPR in Europe; and a number of high-security implementations related to local police and other government bodies. 1) Secure the environment Start by securing the environment that your application and distributed data will be in. This includes securing ports required for application access as well as securing file paths or directories used by the application that could expose sensitive data such as the temporary directories. 2) Encrypt data at rest and in flight Encrypt the data, the communication channels, and anything that connects to and from applications. From a high level, this goes without saying. From an implementation perspective, it can be less prescriptive. There are three main areas of concern around distributed data encryption: client-to-server communications and connections; the data itself; and the inter-node channels of communication. All three of these areas of vulnerability should be encrypted, but there are options to consider. For encryption of the communication channels, the inter-node channels, and client-to-server connections, use TLS over SSL. While both protocols provide strong encryption algorithms, SSL is considered the predecessor to TLS. For data at rest, there are a few ways to go about this. The typical best practice is to encrypt your entire disk volume. This is simply the safest way to encrypt data at rest because everything on the disk is encrypted. The entire volume becomes inaccessible without the encryption key(s). Having said that, if the ability or functionality to encrypt the volume isn’t available or provides too much of a performance penalty, then at minimum encrypt the application data at rest through the application’s database by encrypting the tables or keyspaces themselves. Encrypting these channels requires encryption keys, which you can manage and keep locally or manage off-server through a key management interoperability protocol. 3) Use an authentication and authorization layer Use some level of authentication to ensure users who are attempting to access the system are registered and are who they say they are. Multi-factor authentication, where users have to go through multiple authentication mechanisms to ensure their identity, is quickly becoming the standard for modern applications. But system access is only part of the story. You also need to plan which roles and users have access to which data. Data access should be authorized according to both roles and users. Depending on the tasks of the user, further restrictions may also need to be added. LDAP is a common protocol used for communicating with backing management systems and services that define roles, groups, and permissions. Role-based access control and permissions can also be built into the application’s database by configuring the database’s authentication and authorization rules. 4) Privatize your schemas Distributed systems typically have replicated data. This replicated data not only includes application data for availability purposes but also system data for the database to properly function. Layer in additional security logic on top of that and not only does this information have to be replicated but it may need to exist on each node (where the replication factor equals the number of nodes), which increases the chances of this information being breached. By privatizing system schemas or further restricting access to tables that contain schema information, this can ensure that access is explicitly denied even if the role allows or grants access. 5) Assign and separate roles/duties Enterprises typically have different teams responsible for various aspects of an application, including application developers, database administrators, operators, etc. Each of these roles comes with its own set of rights and privileges. In order to implement an application’s usage and data access patterns into the database access layer, security administrators may need to grant others privileges on database objects that the security administrators themselves cannot access. Without the ability to separate these duties, an administrator would need more access to the database objects to perform this task, weakening the application’s security access protocols. The ability to manage permissions on database objects without requiring access creates a stronger security paradigm. The above is, of course, not an exhaustive list of everything you can do to protect your distributed data. For a comprehensive look into everything you can do, see our security checklist. Achieving Data Security and Compliance with DataStax Enterprise READ NOW
Let’s face it: Securing financial data in the 21st Century is a major headache. There are so many things you need to be thinking about today that you didn’t even have to worry about even five or 10 years ago, such as new compliance laws and regulations, and how to keep sophisticated fraudsters from exploiting all the new touchpoints your customers are using to use your services and/or buy your products. The Equifax breach, which exposed the sensitive personal information of nearly 146 million Americans, is a great example. These types of data breaches not only result in the loss of sensitive, confidential data, but also cause huge financial losses and irreparable damage to brand reputation. This new threat level and high risk exposure is forcing enterprises to rethink how they go about securing their financial data. Simple chip and pin methodologies are obviously no longer enough. You need to be thinking about financial data security from the level of your data layer, because it’s at the data layer where you will be able to launch your most effective and comprehensive defensive against cyber criminals and also most effectively comply with new laws. Approaching financial security from the data layer means using your data for powerful security and compliance, identity management, and fraud protection. But exactly does it work? It’s hard enough to picture the “data layer”, let alone understand how this layer plays into financial data security. It all comes down to your database, and here are the specific abilities your database must possess to protect your financial data and keep your enterprise from becoming the next Equifax. 1. Unified authentication and access control Unified authentication and role-based access controls allow you to easily provision and manage the permissions of users across a variety of sources, including LDAP, Active Directory, and Kerberos. A good data management platform will allow you to utilize multiple sources of authentication and role assignments in the same cluster (e.g. Active Directory for administrators, and Kerberos for applications). You should also have granular access control at the row and column levels, as opposed to just at the table level. Also, if administrators have full access to operate the database but can revoke the access to the data itself, this provides an extra layer of security. 2. End-to-end encryption There’s encryption “at rest” and encryption “in flight”, and end-to-end encryption means protecting against both. Data stored on persistent storage (i.e., disk drives) in an encrypted format is data at rest. Encryption at-rest protects against data exposure in the event of the physical theft of a device, or if an unauthorized party gains access to a system where data is stored but has not gained access to the database yet. Encryption at-rest also offers a degree of protection in environments where storage resources might be re-used, such as in public clouds. The encryption of data as it moves over a network between nodes is encryption in-flight. In a distributed environment, network traffic is constant. If the network is not secure, the data moving between the nodes could be intercepted by an unauthorized party. Hence the need for encryption in-flight. Again - a good data management platform protects you against BOTH. 3. User activity auditing Your data management platform should have integrated user activity auditing in real time, which allows you to record and audit all or a sub-set of user activity, including login attempts, and thus allow you to discover any data breaches or unauthorized behavior almost as they happen. 4. Compliance Whether it’s GDPR, PSD2, SOX, or PCI-DSS, compliance has become a major issue for financial data protection. There are so many ways NOT to comply these days, and so many ways to end up with a major fine or even lawsuit, that handling compliance at the data layer is really your only chance of being totally secure, all the time. A good data management platform can contextualize all data, making it not just possible but easy to discover all the touchpoints and activities of your customers, identify questionable transactions or suspicious behavior, resolve entities, and maintain comprehensive audit trails to meet the mandatory compliance requirements on time, on budget, and in real time. 5. Consumer fraud detection Competent consumer fraud detection and prevention in this day and age requires reliable and quick access to large datasets built using a high volume of transactions or the relationships of data across multiple data silos. Most enterprise do not have the capability to monitor or regulate user behavior across a range of products or business units. As a result, complex fraudulent behavior is often left unchecked, and audits typically require manual intervention across numerous lines of business. A modern data platform will combine a scalable and reliable database with powerful search, analytical, and graph tools to allow you to quickly identify anomalies in user behavior and patterns in real time to detect any fraudulent activity, prevent potential security breaches, and protect financial privacy. Combine all the above into one system That’s the final key. You want to be able to achieve all of the above capabilities with one vendor and not have to go to several different third parties to sew together a quilt of financial data protection that would probably have gaps and could then come easily apart if one of your third parties breaks away from you, or vice versa. One other thing to keep in mind: a lot of data management solutions are built on open source technology, but open source technology, while innovative and leading edge, comes with its own dangers and responsibility. You need to take on internal experts, rely on the open source community for help, and, as evidenced by the Equifax example mentioned earlier, religiously update to stay head of security flaws. That’s why most major enterprises rely on commercial vendors for their data management solutions, even when they’re built on open source technology. DataStax Enterprise offers a comprehensive, advanced data security solution built into our industry-leading data management platform — all with a consistent security model across database, search, and analytics. From compliance to identity management to fraud detection, we’ve got you covered at the data layer. Using Graph Technology to Detect and Prevent Fraud (Webinar) REGISTER NOW