Lab Security Policy: Difference between revisions

From DISI
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
No security system is perfect. There is a tradeoff between safety and ease of use. Our security policy can be summarized as follows: '''You can only access our cluster via ssh from a secure machine'''  What is a secure machine you may ask?  As of Monday, April 21,
No security system is perfect. There is a tradeoff between safety and ease of use. Getting hacked is a big deal. Please be mindful.


* A secure machine is one that we control and can protect.
Our security policy can be summarized as follows:
* The two portals and selected desktops in CCBR 650, 940 and BH 501 are considered secure.  
> '''You can only access our cluster via ssh from a secure machine'''
* Laptops in the lab are currently considered secure, but this is going to change.  
What is a secure machine you may ask?  As of Monday, April 21, our answer is as follows. '''This will change in the coming months.'''
 
* A secure machine is one that we control and can protect. This includes:
** The two portals are secure.
** Desktops we control in CCBR 650, 940 and BH 501 are treated as secure. '''Subject to change.'''
** Laptops in the lab are currently treated as secure. '''Subject to change.'''
** No other machine is treated as secure. This includes the Sali cluster, the QB3 shared cluster, and if you connect via a VPN or ssh tunnel.


* You can only access the portals using an ssh key.  
* You can only access the portals using an ssh key.  
* You can only access the clusters from the portal using a password, never an ssh key.   
* You can only access the clusters from the portals using a password, never an ssh key.   
* You can use ssh keys to move around within the cluster, but only if they are [[How_to_generate_ssh_keys_securely | secure]].
* You can use ssh keys to move around within the cluster, but only if they are [[How_to_generate_ssh_keys_securely | secure]].
* '''Ssh keys must be protected at all times and must never be shared with anyone, even family members or labmates.'''
* '''Ssh keys must be protected at all times and must never be shared with anyone, even family members or labmates.'''
Line 12: Line 18:
If you have any doubts about appropriate use of ssh keys, please ask a [[sysadmin]].
If you have any doubts about appropriate use of ssh keys, please ask a [[sysadmin]].


= Q & A: =
[[Security Q&A]]
 
== Is it lab policy that I can have an ssh key exchange between UCSF and U of T computers? ==
Yes, people can have a sshkey exchange between UCSF and UT computers (only the computers that we maintain, ie monkey.ucsf.edu should NOT have a sshkey).  You '''cannot''' have a ssh key exchange between the portal and the cluster.
 
== Is there any way into the cluster from home other than through a portal machine? ==
No. Currently, there is no other way to access the cluster remotely. Ask if this is a problem for you.
 
== If I lose my laptop or think my account may have been hacked, what is the correct course of action? ==
Send an email to access.bkslab@gmail.com immediately.
 
== Can I copy the private key to as many computers as I like, or should I have one for each computer I want to use to access the cluster? ==
You should use a different ssh key for each computer you want to use to access the cluster.  This way, if one of your computers is compromised, I only have to disable one key and you can still use your other laptop/computer.
 
==  Can I use the same public/private key pair inside the cluster as I use to access the cluster?  Or should we use two different ones? ==
You should use two different ones, one within the cluster and one to access the portal from outside. We will enforce this. Please don't try.  It is no economy.
 
== Can I use key pair exchange to allow me to log in to my colleague's account?  ==
Thus say I am Brian, and I want to allow John to log in as me without my password, can we use ssh keys to allow this?
* NO. This usage is strictly forbidden and will be enforced. Brian must not accept John's public ssh key as an authorized_key.
 
== Do I need to use the portal when I am in the lab? Elsewhere in the university? ==
No, the portal is only needed when accessing the cluster from outside "the lab".  The university is a big place, and we consider most of it to be "outside".  If you have questions about how the borders have been drawn, ask us.
 
We've tried to make this policy easy to understand and remember. We have tried to design something that will not be a burden. If you have suggestions on how to improve these practices, please ask us!


[[Category:Internal]]
[[Category:Internal]]
[[Category:FAQ]]
[[Category:FAQ]]

Revision as of 13:37, 23 April 2014

No security system is perfect. There is a tradeoff between safety and ease of use. Getting hacked is a big deal. Please be mindful.

Our security policy can be summarized as follows: > You can only access our cluster via ssh from a secure machine What is a secure machine you may ask? As of Monday, April 21, our answer is as follows. This will change in the coming months.

  • A secure machine is one that we control and can protect. This includes:
    • The two portals are secure.
    • Desktops we control in CCBR 650, 940 and BH 501 are treated as secure. Subject to change.
    • Laptops in the lab are currently treated as secure. Subject to change.
    • No other machine is treated as secure. This includes the Sali cluster, the QB3 shared cluster, and if you connect via a VPN or ssh tunnel.
  • You can only access the portals using an ssh key.
  • You can only access the clusters from the portals using a password, never an ssh key.
  • You can use ssh keys to move around within the cluster, but only if they are secure.
  • Ssh keys must be protected at all times and must never be shared with anyone, even family members or labmates.
  • Misuse of sshkeys is a very serious matter. Please guard your ssh key access as you would your bank account.

If you have any doubts about appropriate use of ssh keys, please ask a sysadmin.

Security Q&A