A DryDock overview
Deepak GiridharagopalPrincipal Developer
Updated: 2003/10/23 00:55:32
Version: 1.5
Abstract
This guide gives a bird's-eye view of DryDock's architecture. It'll talk about how users interact with the protected document store, how to migrate web developers to using DryDock, and what using DryDock buys you.
1. Opening remarks
This overview will discuss DryDock's functionality in its ideal environment, a dual web server setup. Though it is indeed possible to use DryDock with a single web server, its utility is significantly compromised. Though you'd retian much of DryDock's auditing capabilities, you'd lose any network security benefits. You should really have one web server, protected by a firewall, that your web authors edit content on, and a second web server in a DMZ that holds publicly accessible, production content.
For more information on why this is the One True Way (tm), refer to the DryDock Best Practices Guide. Odds are, though, that if you're an organization that is in need of rigorous publication oversight, you can probably afford another web server. :) If you're still hell bent on getting an idea of how DryDock works with a single server, you can still get through this guide. Just keep in mind that in your case, the production server and the staging server are actually the same machine.
Note: This guide mostly parrots information found in the DryDock 2003 LISA Conference paper [828k PDF]. |
2. How does DryDock work?
DryDock tackles our information security problem in two main ways: by implementing a dual web server setup, and by forcing a separation between creating content and approving its publication.
Figure 2.1 details the process of web publishing using DryDock. DryDock's dual web server setup is comprised of a production machine and a staging machine, both of which have identical web server configurations. The production server holds content suitable for the public and resides in a publicly accessible DMZ while the staging server resides behind the firewall as part of the internal network.
Figure 2.1: Web publishing with DryDock |
 |
The staging server houses a web tree containing files under development (the development tree) and a separate tree containing files authorized for publication (the export tree). The development tree is accessible to web authors on the internal network, while the export tree is solely managed by DryDock.
Approving files for publication
Managers (content approvers) use DryDock's web interface to browse the staging server. The web interface presents an integrated and easily discernible view of the development tree and the export tree which shows them:
- which files from the development tree are authorized for publication
- which files still await approval
- the differences between development and export versions of the same file
- any file's approval history
After looking over an unapproved file and finding it fit for public viewing, a content approver signs the file, instructing DryDock to mark the file as authorized for publication. For added security, DryDock can be configured to require additional information to complete the signing process, such as the name of the document author or a note explaining why the file is being signed.
Once the file is signed, DryDock automatically copies it from the development tree to the export tree. Finally, DryDock synchronizes the staging server's export tree to the production server over SSH, replacing the external web site with an updated copy containing newly signed files.
Removing files from the production web tree
Since the staging server's export tree is separate from the development tree, deleting a file from one will not delete it from the other. To remove a file from the export tree, a content approver uses DryDock's web interface to mark that file as revoked. This removes the file from the set of files copied to the external web server during the next synchronization.
While signing authority is given to a limited number of users, a larger number can be given review authority, or the ability to soft-sign files. Reviewing files follows the same process as signing files, save for two important differences: approval information is optional and can be incomplete, and reviewed files still require an authorized signature for publication. At ARL:UT, review is employed by users to partially fill in approval information for a file so that when a signer moves to authorize that file for publication, much of the data required is already present. Review provides much of the same functionality as signing a file, but without a signature's consequences.
Though DryDock's approval process works well for most documents, rapidly changing documents must be continually re-signed by content approvers for each change to appear on the external web site. To ease dealing with these types of files, a user can sign them as pre-approved; files marked as such will be copied to the production server during synchronization even if their contents have changed since they were signed. Since file pre-approval circumvents DryDock's typical workflow process, we advise our users to apply the option sparingly; users must be vigilant about pre-approved files' content.
3. Web developer migration
Migrating web developers to DryDock's web publishing process should be painless. Instead of placing content directly onto the production server, web developers now place documents onto the staging server. At ARL:UT, we configured our staging server to support the same access methods our web developers have always used: FTP, Samba, and NFS. Since nearly all off-the-shelf web development tools can use at least one these methods to edit pages, we simply instructed our web authors to re-configure their tools to point to the appropriate directory on the staging server.
In most cases, web developers shouldn't have to change their pages for DryDock. In a proper DryDock setup, the staging server's web server environment mimics that of the production server, so properly functioning pages on the staging server will still work when exported to the production machine.
The lone caveat is the avoidance of absolute links: since the production server (not the staging server) will be serving up content to the public, any links in a web page explicitly mentioning the staging server will not work. Relative links solve this problem by not mentioning the server name in the link address; the web server assumes the document is local.
However, there is one situation in which use of a relative link is impossible. If page authors need to refer to a secure page from an insecure page, they need to refer to the host using https:// instead of http://. Since it isn't possible to specify a protocol in a relative link, an absolute link is required. The solution we employed at ARL:UT was to use a simple server-side-include variable that contains the host name of the machine from which the page is served. Page authors then construct an absolute link, using the variable in place of the host name, and the correct server name is inserted dynamically.
4. Benefits to using DryDock
DryDock safeguards against the dissemination of inappropriate web content by codifying a formal document approval process. It ensures that all updates to web content are inspected for propriety before they ever escape the shelter of the internal network. DryDock makes users accountable for the documents they approve; if content is found to be inappropriate, administrators can easily determine who let that content through.
DryDock acts as a document firewall. Just as a traditional firewall regulates the flow of packets to a private network, DryDock regulates the flow of documents to the production web server; they are both access control mechanisms. Through signing, pre-approving, and revoking files, DryDock users create rule sets that manage the movement of documents into and out of its export tree.
DryDock goes to great lengths to log all user and system activity and keep administrators abreast of all changes in web content. DryDock provides administrators with an auditing console that lets them browse DryDock's records. Administrators can inspect the most recent events, all events pertaining to a user, or any events within a specified date range, or they can perform a free-text search to tailor the results to their liking. For greater detail, administrators can peruse DryDock's extensive log files. To immediately notify administrators of changes in content, DryDock can be configured to send out email whenever activity occurs.
With these tools, administrators can easily diagnose problems with content. If a document is approved that is later found to be unsuitable for the public, administrators can refer to the email DryDock sent when the file was signed; the email indicates the parties responsible for approving the file and the file's full path. Administrators can revoke the document's publication or, if necessary, manually restore a previous version of the file using DryDock's revisioning system. They then can use the auditing console to find any other files upon which the responsible parties have recently operated, and handle them as needed.
The DryDock Best Practices Guide indicates how using a dual web server setup can help you operate your production server in a more rigorous and confined network environment than you could normally.
But in addition to network security improvements, DryDock's repeated rebuilding of the production web tree impedes a naïve intruder from simply defacing web pages. The corrupted documents will simply be reconstituted during the next synchronization.
5. Resources
Having read this, it would probably be a good idea to see if DryDock can help your organization. Though I hope that anyone can get some use of it, I'm not going to lie. It's not a silver bullet by any means.
And because I'd be an idiot to not offer screenshots (because people never download stuff that lacks screenshots, right?), you can find a whole slew of them in the DryDock Quick Start Guide.
Following that, if you are interested in more of the lower-level details of how DryDock works, you can either consult the LISA paper or look at the DryDock Mechanics Gudie.
If you've still got questions about DryDock, what it does, how it does, or how it compares to other solutions, feel free to drop a line to the DryDock users mailing list. We could always use company on there. :)
