ITAG - Information Technology Architecture Group

Guidelines

The following statements are meant to provide guidance for design and are the basis for ITAG reviews. The full intent and nuance of these issues is not expressed in these general guidelines. Refer to the more in depth text to understand how these guidelines apply to your situation. There have been, and there will continue to be, circumstances where these guidelines cannot be followed. If you do not think that you can follow a guideline, do not know how to, or would like advice about the issue contact ITAG. There are legitimate reasons for exceptions, and ITAG would like to discuss these case, in order to capture and document best practice, and amend and clarify these guidelines.

All enterprise systems MUST have a public design document prior to development. [Notes on Terminology]

 

1. MIT Network -- Summary of Guidelines

1.1 There is a single shared campus network. (IP)
1.2 The network MUST be considered public and unprotected.
1.3 Unencrypted passwords MUST NOT go across the network.
1.4 Application servers MUST NOT receive or store Kerberos passwords.
1.5 Enterprise Applications SHOULD use the Campus single sign on mechanisms; Kerberos 5 and X509 Certificates. Departmental applications may wish to do so.
1.6 Applications that transmit sensitive information including passwords over the network MUST encrypt the data.
1.7 The MIT network does not have a perimeter firewall.
1.8 IP address of a computer SHOULD NOT be used to determine the location of a machine.
1.9 Applications SHOULD be able to be used across Network Address Translators (NATs).
[Details underlying MIT Network guidelines]

2. Software Standards -- Summary of Guidelines

2.1 Applications SHOULD use open specification and standards where appropriate.
2.2 All protocols SHOULD be open and documented, so that they can be used in any computing environment.
Details underlying Software Standards guidelines]

3. Data -- Summary of Guidelines

3.1 Institute data SHOULD NOT be released to or stored by a third party without an approved business reason.
3.2 Business data created or obtained within the Institute belongs to the institution, not to any particular function, unit, or individual.
3.3 Members of the Institute community MUST ensure that their uses of the business data of the Institute are consistent with the Institute's policy on privacy of information.
3.4 It is the responsibility of the designated custodian of a particular data collection MUST ensure data integrity, security, and accessibility to anyone who demonstrates need.
3.5 Critical and sensitive information MUST be kept on machines that are professionally managed.
3.6 The Warehouse SHOULD be used for reporting where possible.
3.7 Enterprise Data SHOULD be in the Warehouse.
3.8 Data feeds SHOULD come from the Warehouse where possible.
3.9 Systems of Record MUST be established for all shared data.
3.10 Social Security number MUST NOT be used or stored without a clear business need.
3.11 Social Security number MUST NOT be used as the unique identifier or stored.
3.12 All people SHOULD have one unique public id, the MITID number.  All person records SHOULD carry the MITID number.
Details underlying Data guidelines]

4. Identity and Authorization -- Summary of Guidelines

4.1 MIT Certificates, Kerberos credentials and MITIDs SHOULD NOT be used to indicate membership in the MIT community.
4.2 Usernames SHOULD be consistent across systems.  Users SHOULD NOT be assigned a different username than their Kerberos principal.
4.3 Systems that need to restrict access MUST implement some form of authorization.
4.4 Authorization SHOULD be controlled by the central authorization system (Roles).
4.5 Access control SHOULD NOT be based on IP address.
Details underlying Identity and Authorization guidelines]

5. Notes on Terminology

The capitalized terms are based on RFC 2119.

  • MUST: This word, or the terms REQUIRED or SHALL, means that the definition is an absolute requirement of the specification.

  • MUST NOT: This phrase, or the phrase SHALL NOT, means that the definition is an absolute prohibition of the specification.

  • SHOULD: This word, or the adjective RECOMMENDED, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

  • SHOULD NOT: This phrase, or the phrase NOT RECOMMENDED means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.