Confluence and security
Asked by S?lim Ikkache:

Hi all, I have several question, and these questions concern both Confluence Server and SaaS solution.

We need to choose a wiki solution and, functionnaly, we would like to choose Confluence. But our CISO ask a lot of questions that we need to answer :

<br />

1.1. HOW CONFLUENCE DEALS WITH ACCESS CONTROL ?  
Only via a user / pwd connection?  
Is there a way to connect to our internal directory?  
Is there possibility to control by IP source?

<br />

1.2. DATA DIVISION  
How is the data partitioned?  
Is there a tenant management?  
We would like to have a secure access for our whole organization (Digital Branch of the Post Office).

<br />

1.3. RIGHTS MANAGEMENT  
How are managed data access permissions?  
We need three kind of accesses :  
? Public pages: accessible to anyone having the URL  
This concerns user manuals that can be accessed by the general public.  
? Internal Pages La Poste: information that we want to share in our organisation, but not with the whole world, for example, business information: road map, product quality  
? Internal project pages: data such as technical specifications, internal procedures, ... only accessible for the project team

<br />

1.4. ACCESS TO DATA BY THE HOST (Atlassian or the host in case of on premisce)How can we ensure that the data is not accessible by the host?

<br />

1.5 SERVICE AVAILABILITY  
What are the SLAs for service availability?  
How (for the server solution) can we guarantee high availability (server cluster, etc ...)

<br />

1.6. INTEGRITY OF STORED DATA  
Does Atlassian guarantee that it does not modify data, either during transport or when the transformation operations are performed on the servers (either on-site or on the SaaS solution)

<br />

1.7. ACTIONS LOGGING  
Are actions on Confluence logged? If yes, can we access these traces and how ?  
Similarly, are system operation logged? If yes, is there an access?

Thank you for your answers


Answers:
author: Nic Brough -Adaptavist-
body: This is a bit short, but a lot of it is an essay question, probably better answered by a search on Atlassian docs.

Some of these brief answers are dead-ends, there's nothing more to say, but we can expand on most or all of these if you need.

For server:

1.1. HOW CONFLUENCE DEALS WITH ACCESS CONTROL ?

User/password, but you can hook it up to directories, use SSO and customise this with code.

IP by source is up to your network, Confluence won't do it.

<br />

1.2. DATA DIVISION

It is not. The application allows a lot of partitioning by space, but the rest is not.

<br />

1.3. RIGHTS MANAGEMENT  
You do all of that by space permissions.

<br />

1.4. ACCESS TO DATA BY THE HOST

Your data access processes are yours

<br />

1.5 SERVICE AVAILABILITY  
Up to your service team

<br />

1.6. INTEGRITY OF STORED DATA  
Up to your data storage team

<br />

1.7. ACTIONS LOGGING  
There are log files, with a default level of logging, which can be increased if you need more

For Cloud

1.1. HOW CONFLUENCE DEALS WITH ACCESS CONTROL ?

Atlassian accounts, Google accounts, or Atlassian Access (which can be used to hook up to standard LDAP directories you own)

No IP access control

1.2. DATA DIVISION

It is not. The application allows a lot of partitioning by space, but the rest is not.

<br />

1.3. RIGHTS MANAGEMENT  
You do all of that by space permissions.

<br />

1.4. ACCESS TO DATA BY THE HOST

You can't - in order to provide SAAS, Atlassian need access to it

<br />

1.5 SERVICE AVAILABILITY  
See <https://confluence.atlassian.com/support/updated-support-response-slas-951415350.html> and check the Cloud column.

<br />

1.6. INTEGRITY OF STORED DATA  
They will only modify data as part of support or if you ask them to.

<br />

1.7. ACTIONS LOGGING  
Minimal, through the UI (no access to logs)

comments: author: Davin Studer
body: Just to add to points 1.7 for both server and cloud. All page edits and attachment changes are versioned and tagged to the individual that made the change with the ability to rollback any changes.


author: Nic Brough -Adaptavist-
body: Thanks [@Davin Studer](/t5/user/viewprofilepage/user-id/781467) - I was concentrating on the admin/system stuff and completely left out "full content history is part of the system"


author: S?lim Ikkache
body: Thanks a lot


author: S?lim Ikkache
body: I have a complemetary question on the 1.2 DATA DIVISION that I should have called SEGMENTATION OR PARTITIONING OR Defense en depth.

What are the different access control on the data on different layers of the architecture ?

* File System ?
* Database ?
* Application ?

I understood that for application, the access control is user/pwd based. What about hte other layers ?

How the data of our company will be partitionned from the others clients ?

Thank you


author: Nic Brough -Adaptavist-
body: It's the same answer - there is no partitioning. The application, file data and database data is a simple single block.

To look at my Atlassian installation at home, I've got Confluence:

* Install: /opt/confluence, with every directory and file owned by "atlas"
* Data (home): /data/confluence, with every directory and file owned by "atlas"
* Database: run by the default postgres user, with the user "atlas" having a database to which it has full select/create/delete/insert/index rights on everything in it

I could describe the Jira install, the Bitbucket install and so-on exactly the same, although I might vary the owner names.

There is no "partitioning" at these levels.


author: S?lim Ikkache
body: Thank you.

So I understand that the access control is done only at the application level (the db acl mechanism).


author: S?lim Ikkache
body: Other (and lasts) points :

1.4. ACCESS TO DATA BY THE HOST (server solution)

In the case that our confluence server is hosted by an external cloud provider, when you said that "Your data access processes are yours". Ok, but is ther a possibility for the cloud provider to access to my data ? Direct access to the DB, scripting, direct access to the datafiles, and so on.

1.5 SERVICE AVAILABILITY (server solution)  
You said "Up to your service team" ... ok, but my question is : is there technical solutions to install a cluster, a failover, a master-slave, or whatever to guarantee a service availability ?

1.6. INTEGRITY OF STORED DATA  
You said : "Up to your data storage team". Of course, but I need to know if there are means/mecanisms to check the integrity for our data.

1.7 ACTIONS LOGGING

Yet a another point on this one. Is there a way to chack the logs integrity ? What I mean is : if an administrator remove a line from a log, is there a way to detect the change ? (checksum on file logs or whatever) ?  

Thank you for this complement.

Regards


author: Davin Studer
body: 1.4 Confluence server is controlled by you on your servers. Cloud is controlled by Atlassian and they certainly have access to your cloud environment. As for if you decide to install Confluence in a cloud environment like Amazon or Azure then I'm sure the hosting company has some access into the system ... but that is really beyond the scope of anything Atlassian. If you host it on your own in-house servers then you decide who has access.

1.5 There are two flavors of self hosted Confluence. One is server( single machine). The other is data center (multiple machines with replication).

1.7 There is no log checksum that I know of. Consider this though with pretty much any system in existence an administrator could turn off logging altogether. At some point you have to trust your administrators. Yes, the actions they do are logged by the system, but they also probably have the know how to alter the logs if they really wanted to. You could look into a real-time log monitor solution like Splunk or the ELK stack if you wanted to make sure that the logs are in more than one place.


author: S?lim Ikkache
body: Thank you very much, that's all for now. you answered precisely to my questions.