I have .NET Core Web API microservices with MS SQL and elastic search(NoSql). I want to encrypt PII(Personal Identifiable Information) both in Elasticsearch and MS SQL database. Which is better option to use .NET data protection API or always encrypted?.
If I use always encrypted then it will only work with MS SQL. Elastic search + logging will require handling it separately so is it better to encrypt in API using data protection API?.
Documents say that data protection API is only meant for temporary data.
Is there any other better way to protect data other than above too?
Any common pattern or strategy for this?
Depending on your company's industry and internal policy, you might be required to encrypt data AT REST as well as IN MOTION.
Logging PII should be strictly banned. Only log account's internal IDs that can not identify a user, dont log usernames/userids, just account id. Do not log account numbers etc.
As an alternate to elastic search, you could break down the PII data points in to multiple systems to avoid any one system's compromise leading to PII leak.
How to permission a document that can be modified by client but not deleted ?
Does RavenDB have notion of document permission for admin & non-admin users like in other Relational Databases ?
I have a set of documents which will be created only from the RavenDB Dashboard. I want to prevent these handful of documents to be deleted by the client.
Although client should be able to "modify" them, by "modify" I mean append only.
I am assuming we are talking about 4.x version of RavenDB.
On short, no, it is not possible with out of the box functionality.
Authentication and authorization in RavenDB is based on certificates, and functionality-wise is different from what you would typically find in major RDBMS databases.
You can assign roles per client certificate, and those roles would have pre-defined set of operations they can access. You can also restrict which databases certain certificate can access.
But you cannot restrict certain client certificates from deleting a document while allowing to do other operations.
Take a look at the documentation article for more information : https://ravendb.net/docs/article-page/4.2/csharp/server/security/authorization/security-clearance-and-permissions
If I needed to implement such functionality, I would probably place such logic in DAL layer of the application itself.
Background:
Our team is building an inhouse Intranet web application. We are using a standard three layer approach. Presentation layer (mvc web app), Business layer and data access layer.
Sql database is used for persistence.
Web app / iis handles user authentication (windows authentication). Logging is done in business and data access layer.
Question service account vs user specific Sql accounts:
Use service / app account:
Dev team is proposing to set up service account (set up for application only). This service account needs write & read access to db.
Vs
Pass on user credentials to SQL
IT ops is saying that using a service account (specifically created for app only) for db access is not deemed best practice. Set up Kerberos delegation configured from the web server to the SQL server so that you can pass on the Windows credentials of the end users & create a database role that grants the appropriate data access levels for end users
What is the best practice for setting up accounts in sql where all request to db will come through the front end client (ie via bus layer and then data layer)
The Best Practice here is to let the person/team responsible for the database make the decision. It sounds like the dev team wants to forward (or impersonate) some credentials to the DB which I know that some small teams like doing, but yes that can leave things a bit too open. The app can do whatever it likes to the database, which is not much of a separation if you're into that kind of thing.
Personally, if I understand what you're saying above, I do more of what the IT team is thinking about (I use Postgres). In other words my app deploys over SSH using a given account (let's say it's the AppName account). That means I need to have my SSH keys lined up for secure deployment (using a PEM or known_keys or whatever).
In the home root for AppName I have a file called .pgpass which has pretty specific security on it (0600). This means that my AppName account will use local security to get in rather than a username/password.
I do this because otherwise I'd need to store that information in a file somewhere - and those things get treated poorly pushed to github, for instance.
Ultimately, think 5 years from now and what your project and team will look like. Be optimistic - maybe it will be a smashing success! What will maintenance look like? What kinds of mistakes will your team make? Flexibility now is nice, but make sure that whomever will get in trouble if your database has a security problem is the one who gets to make the decision.
The best practice is to have individual accounts. This allows you to use database facilities for identifying who is accessing the database.
This is particularly important if the data is being modified. You can log who is modifying what data -- generally a hard-core requirement in any system where users have this ability.
You may find that, for some reason, you do not want to use your database's built-in authentication mechanisms. In that case, you are probably going to build a layer on top of the database, replicating much of the built-in functionality. There are situations where this might be necessary. In general, this would be a dangerous approach (the database security mechanisms probably undergo much more testing than bespoke code).
Finally, if you are building an in-house application with just a handful of users who have read-only access to the database, it might be simpler to have only a single login account. Normally, you would still like to know who is doing what, but for simplicity, you might forego that functionality. However, knowing who is doing what is usually very useful knowledge for maintaining and enhancing the application.
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
I know that LDAP is used to provide some information and to help facilitate authorization.
But what are the other usages of LDAP?
I will focus on why using LDAP, not what is LDAP.
The use model is similar like how people use library cards or phonebooks. When you have a task that requires “write/update once, read/query many times”, you might consider using LDAP. LDAP is designed to provide extremely fast read/query performance for a large scale of dataset. Typically you want to store only a small piece of information for each entry. The add/delete/update performance is relatively slower compared with read/query because the assumption is that you don’t do “update” that often.
Imagine you have a website that has a million registered users with thousands of page requests per second. Without LDAP, every time users click a page, even for static page viewing, you will probably need to interact with your database to validate the user ID and its digital signature for this login session. Obviously, the query to your database for user-validation will become your bottleneck. By using LDAP, you can easily offload the user validation and gain significant performance improvement. Essentially, in this example, LDAP is another optimization layer outside your database to enhance performance, not replacing any database functions.
LDAP is not just for user validation, any task that has the following properties might be a good use case for LDAP:
You need to locate ONE piece of data many times and you want it fast
You don’t care about the logic and relations between different data
You don’t update, add, or delete the data very often
The size of each data entry is small
You don’t mind having all these small pieces of data at a centralized place
That's a rather large question.
LDAP is a protocol for accessing a directory. A directory contains objects; generally those related to users, groups, computers, printers and so on; company structure information (although frankly you can extend it and store anything in there).
LDAP gives you query methods to add, update and remove objects within a directory (and a bunch more, but those are the central ones).
What LDAP does not do is provide a database; a database provides LDAP access to itself, not the other way around. It is much more than signup.
Well, there are LDAP servers and the LDAP protocol. Combined, it's a data store, or a database. It's not relational, but it's just a place to store data, and it's optimized to be efficient at reads more than writes. It doesn't support transactions.
Now, it happens to be very popular for storing credentials, but that's by no means its only purpose, and not its original purpose.
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. The nitty-gritty details of LDAP are defined in RFC2251 "The Lightweight Directory Access Protocol (v3)" and other documents comprising the technical specification RFC3377. This section gives an overview of LDAP from a user's perspective.
What kind of information can be stored in the directory? The LDAP information model is based on entries. An entry is a collection of attributes that has a globally-unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The types are typically mnemonic strings, like cn for common name, or mail for email address. The syntax of values depend on the attribute type. For example, a cn attribute might contain the value Babs Jensen. A mail attribute might contain the value babs#example.com. A jpegPhoto attribute would contain a photograph in the JPEG (binary) format.
How is the information arranged? In LDAP, directory entries are arranged in a hierarchical tree-like structure.
LDAP is the Lightweight Directory Access Protocol. Basically, it's a protocol used to access data from a database (or other source) and it's mostly suited for large numbers of queries and minimal updates (the sort of thing you would use for login information for example).
LDAP doesn't itself provide a database, just a means to query data in the database.
The main idea of LDAP is to keep in one place all the information of a user (contact details, login, password, permissions), so that it is easier to maintain by network administrators. For example you can:
use the same login/passwd to login on an Intranet and on your local computer.
give specific permissions to a group of user. For example some could access some specific page of your Intranet, or some specific directories on a shared drive.
get all the contact details of the people in a company on Outlook for example.
The main benefit of using LDAP is that information for an entire organization can be consolidated into a central repository. For example, rather than managing user lists for each group within an organization, LDAP can be used as a central directory accessible from anywhere on the network. And because LDAP supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS), sensitive data can be protected from prying eyes.
LDAP also supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited for the type of information the server is to disseminate. Because LDAP also has a well-defined client Application Programming Interface (API), the number of LDAP-enabled applications are numerous and increasing in quantity and quality.
LDAP main usage is to provider faster retrieval of data . It acts as a central repository for storing user details that can be accessed by various application at same time .
The data that is read various time but we rarely update the data then LDAP is better option as it is faster to read in it because of its structure but updating(add/updatee or delete) is bit tedious job in case of LDAP
Security provided by LDAP : LDAP can work with SSL & TLS and thus can be used for sensitive information .
LDAP also can work with number of database providing greater flexibility to choose database best suited for our environment
Can be a better option for synchronising information between master and its replicase
LDAP apart from supporting the data recovery capability .Also , allows us to export data into LDIF file that can be read by various software available in the market
I have had the opportunity to start a project for school about ldap, from scratch, but before getting to know what is ldap, I had to understand what is a directory, there are many (most used directories are novell and windows), here you can see what the directory in Wikipedia.
And ldap is the protocol to communicate with the board, one of the best books I've found is this one.
LDAP is just a protocol to access structured information. LDAP has standardized local and remote access to information whereas in case of database there is only standardized local access and remote access is proprietary.
LDAP server is optimized for search operation and database for transactions(Insert/Delete).
For more information refer following link:
http://www.itszero.in/2013/09/what-is-ldap-ad-adam.html
In Windows Server LDAP is a protocol which is used for access Active Directory object, user authentication, authorization.
To take the definitions the other mentioned earlier a bit further, how about this perspective...
LDAP is Lightweight Directory Access Protocol. DAP, is an X.500 notion, and in X.500 is VERY heavy weight! (It sort of requires a full 7 layer ISO network stack, which basically only IBM's SNA protocol ever realistically implemented).
There are many other approaches to DAP. Novell has one called NDAP (NCP Novell Core Protocols are the transport, and NDAP is how it reads the directory).
LDAP is just a very lightweight DAP, as the name suggests.
Well,
LDAP is a protocol(way) to access structured info. LDAP uses client-server model so, LDAP client makes request to access required info. LDAP server stores info not in relational way but in attribute and value pair. You can use LDAP to assign same privilege to group of user or same credential to access multiple services. For more details refer following link : http://www.zytrax.com/books/ldap/ch2/
LDAP stands for Lightweight Directory Access Protocol.It is used in Active Directory for communicating user queries..e.g.. LDAP can be used by users to search and locate a particular object like a laser printer in a domain.
LDAP is also used to store your credentials in a network security system and retrieve it with your password and decrypted key giving you access to the services.
Light weight directory access protocal is used to authenticate users to access AD information
LDAP stands for Lightweight Directory Access Protocol (not a database). As the name says it is used for accessing/reading data. LDAP is a protocol to access data from directory servers which is a hierarchical database, it is designed for reading, browsing, searching, and organizing data. This kind of data we do not modify regularly or it is very infrequently modified data.
Big companies store their internal data, for example, user names with their title and id or phonebooks of their workers on LDAP servers (this server implements a tree-structured database). Those data can be reached by the workers of that company through the LDAP protocol. LDAP protocol runs over TCP or UDP protocol and accesses the server through port 389. There is also LDAPS that runs over SSL and accesses the server through port 636.