{"id":550,"date":"2017-06-15T15:45:04","date_gmt":"2017-06-15T19:45:04","guid":{"rendered":"https:\/\/sites.haa.pitt.edu\/preservationroadmap\/?page_id=550"},"modified":"2017-06-15T15:45:04","modified_gmt":"2017-06-15T19:45:04","slug":"c4-permissions-data-integrity","status":"publish","type":"page","link":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/c4-permissions-data-integrity\/","title":{"rendered":"Module C4: Permissions & Data Integrity"},"content":{"rendered":"
Module Status<\/em>: Drafting in Progress<\/span> | Ready for Testing<\/span> | Tested<\/span><\/div>\n\n\n\n
Current Module Downloads: Module C4 Activity Worksheet<\/a><\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n

The activities discussed in this module focus on protecting and maintaining the integrity of your work over time, from the platform level down to the bit level. The permissions section asks you to assess which team members have read, write, and delete authorizations for each technology used. The data integrity section details actions that will help project members ensure that the files they are preserving remain, if desired, fixed or unchanged.<\/p>\n

Permissions<\/h3>\n

This area is primarily dedicated to determining and documenting which team members have access to the technological components of\u00a0 your project and what actions they are allowed to perform. At Level 1, this means identifying who has read, write, and delete permissions for specific files, whereas at Level 4, this means creating and auditing logs of all actions taken on your files in order to closely monitor change and prevent loss. If your project needs and\/or uses version control software such as Git or Subversion, you may already be working at Level 3 in this area.<\/p>\n

Working through this section, you will find it helpful to refer back to Module B1<\/a>, where you identified project members and roles,\u00a0Module B2<\/a>, where you identified your project’s technological infrastructure, and Module B3<\/a>, where you’ve made connections between staff and technology. If you’ve worked through those each of those modules, you’ll find that you’re already in good standing to address the sustainability levels detailed below. Monitoring staff access and permissions is important not only for preventing accidental data losses or changes, but also for preparing for transition planning in the event that a project team changes.<\/p>\n\n\n\n\n
<\/td>\nLevel 1<\/strong><\/td>\nLevel 2<\/strong><\/td>\nLevel 3<\/strong><\/td>\nLevel 4<\/strong><\/td>\n<\/tr>\n
Permissions<\/strong><\/td>\nIdentify which project members have login credentials to accounts and services used\u00a0<\/span><\/p>\n

Identify which project members have read, write, move, and delete authorization to individual files<\/span><\/td>\n

Restrict authorizations to only necessary team members<\/span><\/p>\n

Document access restrictions for services and files<\/span><\/td>\n

Maintain logs of who performs what actions on files, including deletions and preservation actions<\/span><\/td>\nPerform routine audits of activity logs<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Data Integrity<\/h3>\n

The second area in this module, Data Integrity, focuses on the physical attributes of the digital content itself. The activities in this area are intended to ensure that you are preserving the digital materials you intend to preserve, and that changes to files at the bit level do not go unnoticed.<\/p>\n

Straight away, you will certainly notice that the Level 1 behaviors for this area are identical to the Level 1 behaviors for the “Permissions” area above. This is because the first line of defense against data corruption is recognizing that people are capable of making mistakes, and that restricting access to files is not always about trust. It is also about limiting risk. Knowing who has access to perform which actions on which platforms and which files is good project management and is the first, best thing you can do to help protect the integrity of your data.<\/p>\n

Level 2 introduces the professional notion of “fixity<\/a>.”\u00a0Put simply, fixity refers to a digital object’s quality of being fixed or unchanged. To create fixity information, you can use\u00a0a checksum or cryptographic hash. For a more in-depth explanation of fixity, see the NDSA publication “Checking Your Digital Content: What is Fixity and When Should I Be Checking It?<\/a>” To learn more about cryptographic hashes, see this post by Bill LeFurgy from the Library of Congress’s blog, The Signal<\/em>, “Hashing Out Digital Trust<\/a>.” Some off-the-shelf content management systems, such as CollectiveAccess, create checksum information upon ingesting digital files, so do check in with your system documentation to find out if you are already performing this activity.<\/p>\n

However, simply creating fixity information will not be enough to actually offer you sustaining help should something go wrong\u2014knowing that a file has been corrupted will not do much good without being able to repair the issue. For this reason Level 2 also indicates that you must also be able to replace corrupted information when you find out that there is a problem. To assure yourself that this would be possible, please refer back to your work in Module C2<\/a>, specifically in the section on Backing Up Your Work. Will you have sufficient copies, and access to those copies, to repair any corrupted files?<\/p>\n

It is particularly important in this area to remember that each of these levels may not be applicable to every project. Fixity information is likely to be more valuable in some projects than in others: namely, it may not be very meaningful to check and regularly update the fixity information of files that are being actively developed or altered<\/strong> because it is in the nature of such information to keep changing over time. On the other hand, if your project is centered on a curated collection of stable digital images, the fixity information of those files may be mission-critical. Keep this in mind as you consider your ideal level in this area.<\/p>\n\n\n\n\n
\u00a0<\/strong><\/td>\nLevel 1<\/strong><\/td>\nLevel 2<\/strong><\/td>\nLevel 3<\/strong><\/td>\nLevel 4<\/strong><\/td>\n<\/tr>\n
Data Integrity<\/strong><\/td>\nIdentify which project members have login credentials to accounts and services used<\/p>\n

Identify which project members have read, write, move, and delete authorization to individual files<\/td>\n

Be able to replace\/repair corrupted data<\/p>\n

Create fixity information for stable project files<\/td>\n

Check fixity of stable content at fixed intervals<\/td>\nCheck fixity of stable content in response to specific events or activities<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Additional Resources<\/h4>\n

Bailey, Jefferson, \u201cProtect Your Data: File Fixity and Data Integrity.\u201d <\/span>Library of Congress The Signal Blog<\/span><\/i>. April 7, 2014. <\/span>https:\/\/blogs.loc.gov\/thesignal\/2014\/04\/protect-your-data-file-fixity-and-data-integrity\/<\/span><\/a>.\u00a0<\/span><\/p>\n

De Stefano, Paula, et al. \u201cWhat is Fixity and When Should I Be Checking It?\u201d <\/span>Checking Your Digital Content: An NDSA Publication<\/span><\/i>. Accessed September 23, 2022. <\/span>http:\/\/www.digitalpreservation.gov\/documents\/NDSA-Fixity-Guidance-Report-final100214.pdf<\/span><\/a>.\u00a0<\/span><\/p>\n

Gladney, H. M. and J. L. Bennett. \u201cWhat Do We Mean by Authentic? What\u2019s the Real McCoy?\u201d <\/span>D-Lib Magazine<\/span><\/i> 9, no. 7\/8 (2003). <\/span>http:\/\/www.dlib.org\/dlib\/july03\/gladney\/07gladney.html<\/span><\/a>.\u00a0<\/span><\/p>\n

Hedstrom, Margaret L., Christopher A. Lee, Judith S. Olson, and Clifford A. Lampe. \u201c\u2019The Old Version Flickers More:\u2019 Digital Preservation from the User\u2019s Perspective.\u201d <\/span>American Archivist<\/span><\/i> 69, no. 1 (Spring\/Summer 2006): 159-187. <\/span>https:\/\/doi.org\/10.17723\/aarc.69.1.1765364485n41800<\/span><\/a>.\u00a0<\/span><\/p>\n

Zwaard, Kate. \u201cHashing Out Digital Trust.\u201d <\/span>Library of Congress The Signal Blog<\/span><\/i>. Accessed September 23, 2022. <\/span>https:\/\/blogs.loc.gov\/thesignal\/2011\/11\/hashing-out-digital-trust\/<\/span><\/a>. <\/span><\/p>\n

(Module last updated June 2017<\/span>)<\/em><\/p>\n\n\n\n
Previous Module: Module C3: File Formats & Metadata<\/a><\/th>\nNext Module: Module C5: Digital Sustainability Action Plan<\/a><\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n
Back to Section\u00a0C Overview<\/a><\/h5>\n","protected":false},"excerpt":{"rendered":"

Module Status: Drafting in Progress | Ready for Testing | Tested Current Module Downloads: Module C4 Activity Worksheet The activities discussed in this module focus on protecting and maintaining the integrity of your work over time, from the platform level down to the bit level. The permissions section asks you to assess which team members […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":12,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-550","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/pages\/550","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/comments?post=550"}],"version-history":[{"count":0,"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/pages\/550\/revisions"}],"wp:attachment":[{"href":"https:\/\/sites.haa.pitt.edu\/sustainabilityroadmap\/wp-json\/wp\/v2\/media?parent=550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}