9 Replies Latest reply on Nov 18, 2016 4:34 PM by Russell Christopher

    Security of embedded credentials

    Jamison Johnson

      Howdy,

       

        I am wondering if anyone has any information on the security of using the embedded credentials option for publishing data sources linked to live SQL databases. I understand how to set it up, but am wondering what the risks are from a security perspective... exactly how secure are the embedded credentials? I have researched the options, but am not clear exactly on how the live connections work. In the documentation, for live connections, it states that it establishes a pass through. But other information I have read leads me to believe that the connection is directly between desktop and the live DB. Does Tableau server "proxy" the data connection between desktop and the live DB when accessing a published data source, or are the credentials sent to desktop and it establishes a direct connection to the DB server?

       

         I am an IT lead and am trying to determine the most secure way to grant access to data collected by our custom built web applications and stored in internally grown databases among our various employees and departments. These databases are generally not open to our employees and the relevant data must be accessed through reporting code on the application front-end. However, we are looking at ways to use Tableau to empower our end users to better meet their own needs without needing OIT resources. I am wanting to build out a data source for each of our primary DBs/regions and allow the end user to use them to build their own custom worksheets. We have created a specific user for Tableau use that contains the datareader role (read-only). But I am not certain if I like the idea of DB credentials being disseminated out to various external users and departments that have a lower "trust" level. I know our security team will have concerns about the integrity of the credentials if they are embedded in the data source; however, they will not want to establish an individual DB user for every employee who wishes to use the data source in Tableau.

       

          I am also considering possibly ditching the live DB approach in favor of frequently refreshed extracts. Anyone who has handled a similar scenario have any thoughts? Thanks.

       

       

       

      JJ

        • 1. Re: Security of embedded credentials
          Patrick A Van Der Hyde

          Hello Jamison Johnson,

           

          Thank you for this question and I'm sorry their has been no response so far.  I have moved this thread to the Server Administration area of the forums and I've alerted a few employees that work with Server to try and find a potential answer internally. 

           

          Patrick 

          • 2. Re: Security of embedded credentials
            Patrick A Van Der Hyde

            Hello Jamison,

             

            I checked and for the first question - how are the credentials stored by server?  They are encrypted in the Tableau Postgres DB on Server.

            The second question - you are right, Tableau Server acts as a proxy for the data and does not send credentials to desktop. 

             

            Does that answer your questions?

             

            Patrick 

            1 of 1 people found this helpful
            • 3. Re: Security of embedded credentials
              Toby Erkson

              Jamison Johnson wrote:

               

              1) exactly how secure are the embedded credentials? I have researched the options, but am not clear exactly on how the live connections work. In the documentation, for live connections, it states that it establishes a pass through. But other information I have read leads me to believe that the connection is directly between desktop and the live DB. Does Tableau server "proxy" the data connection between desktop and the live DB when accessing a published data source, or are the credentials sent to desktop and it establishes a direct connection to the DB server?

               

              2)  I am an IT lead and am trying to determine the most secure way to grant access to data collected by our custom built web applications and stored in internally grown databases among our various employees and departments. These databases are generally not open to our employees and the relevant data must be accessed through reporting code on the application front-end. However, we are looking at ways to use Tableau to empower our end users to better meet their own needs without needing OIT resources. I am wanting to build out a data source for each of our primary DBs/regions and allow the end user to use them to build their own custom worksheets. We have created a specific user for Tableau use that contains the datareader role (read-only). But I am not certain if I like the idea of DB credentials being disseminated out to various external users and departments that have a lower "trust" level. I know our security team will have concerns about the integrity of the credentials if they are embedded in the data source; however, they will not want to establish an individual DB user for every employee who wishes to use the data source in Tableau.

               

              3)  I am also considering possibly ditching the live DB approach in favor of frequently refreshed extracts. Anyone who has handled a similar scenario have any thoughts? Thanks.

              I've been trying to answer your question over the course of a few hours but my knowledge is limited.  A Tableau Support person may be of better assistance but here's a shot to get the conversation going...

               

              "Data source" can be ambiguous so I use "db data source" when talking about the original location of the data, like Excel or Oracle or SalesForce or WDC etc. while "data source" is used to mean the object on the Tableau Server (i.e. a published data source) or the object in a workbook (i.e. in the Data Sources tab).

               

              1)  Passwords are encrypted.  When one opens a workbook in Desktop they will be challenged for a password, so even a Tableau Administrator can't just look at data sources with impunity!  Desktop connects directly to the data source if it is embedded in the workbook.  If the data source is one that is published on the Tableau Server then the Desktop workbook connects to the published data source on the Tableau Server which then [the Tableau Server] connects to the original db data source (MS SQL Server, DB2, Oracle, etc.), thus Desktop > Tableau Server > db data source.  If the published data source is an extract then it's simply Desktop > Tableau Server; when the extract gets refreshed it is Tableau Server > db data source but the workbook doesn't connect to the db data source itself.

               

              3)  I think this would be best given your concerns.  Data sources could then be considered "certified" as a single version of the truth and with credentials embedded there's no need to worry about people using them and running off on their own.  Depending upon the level of trust or need (data scientists?) you may have a few super-users that are allowed all-access to the data sources -- they can have unique user IDs so you know if they give out their credentials to others with a simple custom admin report.

               

              2)  (Yes, my answers are NOT in order )  Hmm...  Correct in that you don't want to have unique credentials for everyone!  Service accounts are best so long as they have non-expiring passwords!!!  You may want to have several accounts depending on the data source and levels of information to make available.  While the user ID will be visible the password will remain blank if someone opens a workbook in Desktop so you don't have to worry about people finding out a password in that manner, however, as you know all it takes is one person to share the credentials and suddenly it becomes common knowledge to the community.  It is a dilemma so see bullet #3 above.

              • 4. Re: Security of embedded credentials
                Russell Christopher

                In regards to your question about moving to rapidly refreshing extracts instead of doing live connections:

                 

                If your databases are relatively quick, then (in my opinion) there's no real reason to do this...in addition:

                 

                • You create more work for yourself around creating and managing extract schedules
                • You create more "moving parts" in your solution (with the associated increased chance that something will go wrong)
                • You pay the cost of rapid extract refreshes on your Tableau Server. These resources could be used to render vizzes instead, so you'll end "running out of Tableau" faster
                • A live connection to certain databases gives you some flexibility in terms of problem-solving with Tableau. For example: Need to write some "real code" to answer a particularly difficult question? You can drop it right in your database and then call it interactively with rawSQL. Not possible if you're extract only - your answers become static

                 

                Bullet #3 is the biggie for me - you're "wasting" Tableau Server here. I'd recommend you use extracts where you need them, but not just because you can.

                1 of 1 people found this helpful
                • 5. Re: Security of embedded credentials
                  Justin D'Cruze

                  100% with Russell regarding point 3, extracts make sense for performance gains......or maybe if you have some really weird use cases (e.g. if you database updates real time but you actually need a static copy of data from a specific time periodically).

                   

                  Another thing with extracts, I would say they are slightly more of a data security risk. The reason being if you allow download on your workbooks/datasources, with live connects that user who downloads it still needs to know the credentials to pull any data. Whereas with extracts, once it's downloaded it could potentially be emailed around and anyone with Desktop can view that extract.

                  Easily solved by applying the right permissions, but still probably worth considering.

                  • 6. Re: Security of embedded credentials
                    Toby Erkson

                    Russell & Justin,

                    I disagree about #3 because db credential sharing is a concern for them (based upon the information given).  By having IT set up the data sources and making them extracts they don't have to worry about unauthorized access to the actual db data source.

                     

                    I agree that a [fast] live connection would be better instead of a bazillion extracts.

                    • 7. Re: Security of embedded credentials
                      Toby Erkson

                      Justin D'Cruze wrote:

                       

                      ...

                       

                      Another thing with extracts, I would say they are slightly more of a data security risk. The reason being if you allow download on your workbooks/datasources, with live connects that user who downloads it still needs to know the credentials to pull any data. Whereas with extracts, once it's downloaded it could potentially be emailed around and anyone with Desktop can view that extract.

                      Easily solved by applying the right permissions, but still probably worth considering.

                      I basically had the same conversation about information security with our security architecture team when I wanted Guest access turned on.  It essentially boiled down to employee trust.  There are many ways to get information out and people will find the way to do so if they're so inclined.  No different than having the credentials and dumping into Excel and emailing that out.  Information security might be a good topic for one of the Tableau Server project managers for the next Tableau Conference

                      • 8. Re: Security of embedded credentials
                        Brian Vinson

                        Thank you, Russell. That is the most succinct explanation of Extracts I've seen.

                        • 9. Re: Security of embedded credentials
                          Russell Christopher

                          Yeah, this is all different flavors of "pick your poison", I guess. You're going to feel some pain somewhere, so where do you want it?