gnumed-doc 1.1.7-1 / usr / share / doc / gnumed / user-manual / GmManualAccountManagement.html

<h1><a name="Access_Control_and_Account_Manag"></a> Access Control and Account Management </h1>
<p />
An outline of concepts and approaches that govern access to the server. Some (sudo) may be inapplicable to Windows systems.
<p />
There are four basic levels of access to consider in a GNUmed system:
<p /> <ul>
<li> physical machine access
</li> <li> OS level access
</li> <li> database level access
</li> <li> application level access
</li></ul> 
<p />
<a name="PhysicalAccess"></a>
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Physical_machine_access"></a> Physical machine access </span></h2>
<p />
This is the level where anything goes. Even without knowing any passwords one can boot up the machine from a live CD and copy or change anything on the machine as wanted. If necessary the machine can be disassembled and reassembled in a way that permits access (as in removing hard drives).
<p />
The only protection against this is encryption and not storing the key on the machine.
<p />
This is why U.S. Customs desires the powers to apply torture when Grandma and her laptop enter the U.S. for Thanksgiving.
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="OS_level_access"></a> OS level access </span></h2>
<p />
<strong>Root account</strong>
<p />
The <em>root</em> account for a server affords total control of the machine, including the ability to permanently prevent any and all access by others. Accordingly, any sharing of the root account, particularly for a server that would hold clinical data, must be kept to an extreme minimum. No one who cannot be absolutely trusted, or whose loyalties and integrity could ever be questioned, should be given access to the root password, lest they could change and it and hijack the server, or sneak their way into dubious activity.
<p />
If it were ever necessary to grant root access to someone for whom sudo access would not be enough (see sudo access below) then you must seriously consider changing the root password temporarily while witnessing the individual's work, and then changing it back.
<p />
At the same time, if many people would depend on this server, then the root password must exist somewhere more than just the memory of one person. At minimum, two trusted people must know it, and/or it must be somewhere recorded, and kept safe. Alternatively, if only one person is to know the password, access can nearly always be retrieved by accessing the machine <a href="GmManualAccountManagement.html#PhysicalAccess" class="twikiCurrentTopicLink twikiAnchorLink">physically</a>.
<p />
It goes without saying that the root password must be nontrivial. Not only must it not be a person's name, and not only must it not be a word present in any language dictionary and not any known date of birth or address or phone number which may relate to you, but it should MINIMALLY be 12 and preferably 20 characters in length and consist of a mix of upper and lower case letters, numbers, and symbols.
<p />
If your situation warrants a password that cannot be remembered, in other words if it needs to be so challenging that it can only really ever be copied and pasted, you could obtain a password from <a href="https://www.grc.com/passwords.htm" rel="nofollow" target="_top">grc.com "Perfect Passwords"</a> and save that to two or more USB keys or disks. Keeping those in a "safe place" also goes without saying.
<p />
<strong>Sudo access</strong>
<p />
Sudo access (SUper user DO) is the next most powerful access to a server. Armed with sudo access, a user can do nearly everything as root or another system user only limited by the entries in =/etc/sudoers.
<p />
Sudo access should only ever granted to the individual system user accounts of actual humans. Sudo should not be granted to a system user account whose use might pass among more than one person, such as a system account <em>gmadm</em> which may have been set up to allow people to administer the gnumed databases.
<p />
<strong>System administrator accounts</strong>
<p />
These are system user accounts which individuals may "assume" in the course of administering one or more aspects of the server. It may be possible to disallow these accounts from connecting from the outside world, requiring people to instead connect under their own account, and then "switching" by means of the "su" (Switch User) command into the administrative account.
<p />
<em>gmadm</em> is an example of an administrative account which may have been set up to allow people to administer the gnumed databases.
<p />
Anyone with sudo access would be able to switch into one of these administrative accounts without needing to know the administrative account's password. They could even alter, reset, or lock the administrative account's password. People without sudo access would need to know the password. (This outline does not consider the creation of a "group", which is another method of managing access).
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Application_level_access"></a> Application level access </span></h2>
<p />
<strong>Application (program)-specific system user accounts</strong>
<p />
Each program or application that is running on a server has the possibility of being owned and operated by a nonhuman account which, when they would be a system account, typically have no home directory or disk space assigned to them. Many of them start and run automatically, or at intervals, in order to take care of regular or intermittent tasks. Humans can "become" these accounts (through "su") in order to manually undertake certain tasks.
<p />
Postgres is one such system user account. Mirth, a system for managing HL7 messages and which can be used to import these into GNUmed, can be another such account.
<p />
Accounts like <em>postgres</em> are considered the super-user of the application, as opposed to root which is the superuser of the server overall. As such, <em>root</em> would be able to alter or lock the postgres password, or even delete the <em>postgres</em> account, not that you would want to do this. Although it might be rarely necessary if you had to remove and reinstall the entire PostgreSQL system, after having backed-up, of course!
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Database_level_access"></a> Database level access </span></h2>
<p />
<strong>GNUmed accounts</strong>
<p />
We have already noted the possibility of creating a system-level account <em>gmadm</em> to assist operations at the server level.
<p />
We also need at least one "postgres" account dedicated to the administration of GNUmed from the "inside" of the postgres database server. For this purpose, we have designated <em>gm-dbo</em> as the "owner" (within postgres) of the GNUmed database.
<p />
Beyond the <em>gm-dbo</em> account, we will need individual accounts for each of the people (doctors, other clinicians, support staff) who will be entering data into GNUmed and interacting with the data that is in the GNUmed EMR. This is covered in the topic <a href="GmManualManagingUsers.html" class="twikiLink">GmManualManagingUsers</a>.
<p />
<hr />
<p />
<hr />