| Oracle® Collaboration Suite Deployment Release 2 (9.0.4) Part Number B15606-01 |
|
|
View PDF |
| Oracle® Collaboration Suite Deployment Release 2 (9.0.4) Part Number B15606-01 |
|
|
View PDF |
This chapter provides an overview of Oracle Collaboration Suite network services and components, and describes strategies and questions to consider when planning your network. This chapter contains the following topics:
Separation of Traffic in a Typical Installation of Oracle Collaboration Suite
General Network Considerations for Oracle Collaboration Suite
Questions to Ask about an Existing Network Before Deploying Oracle Collaboration Suite
When planning your network, you want to take advantage of Oracle Collaboration Suite's features while making the most out of your existing network services and components. You must determine factors such as how much access you want to allow from external sources, how much capacity is required to meet the needs of your users, how available you need your network to be, what your budget allows and what your business reasons are for setting these goals.
You should also be ready to contemplate how much (or how little) you are willing to change in your network, and whether or not you have the mandate or flexibility to update business processes if necessary.
In smaller deployments of Oracle Collaboration Suite, network and architectural planning become intertwined. This is because the smaller the pool of available servers, the fewer options there are for deployment. When you are planning an architecture with only one or two servers, there will often be a trade-off between component accessibility and location of servers. Security demands often dictate where certain servers must reside, and access to these servers must be planned accordingly. This can easily be done with the proper use of network services.
Access and security are two characteristics of Oracle Collaboration Suite that must be planned simultaneously, because they directly affect one another. This is especially true in smaller deployments.
Access is arguably the more complex of these two issues. In virtually any deployment, you must account for a number of access methods (or levels) within a single environment. These access methods depend on the user's location when attempting to access the network, whether or not a thick or thin client is used and the component to which the user is attempting to connect.
Because access is such a network-dependent element, much of its setup depends on the surrounding network environment. Therefore, Domain Name Services (DNS), mail relays, reverse proxies, firewalls, network routing and other such network services must interact very closely with the components of Oracle Collaboration Suite. Understanding this interaction is the key to understanding Oracle Collaboration Suite network access in a production environment.
Security is a subset of access in many ways, as many security issues are solved simply by denying access to certain services or networks; for instance, by denying access to IMAP from the outside world. The other element to consider is how to secure the traffic you do allow to flow, and this is where encryption plays an important role. This is especially true for external traffic.
Another critical, and often overlooked, element of security is the planning and management of administration accounts on your servers. Due to the number of administrative accounts—which provide both management flexibility and manageability—there is also the potential for a large number of passwords, and administrators are tempted to use the same password for all accounts. This is a bad idea for obvious reasons. Planning and managing the use of different passwords for different accounts improves security for your Oracle Collaboration Suite installation.
A typical installation of Oracle Collaboration Suite separates traffic in two ways.
Internal Traffic
Internally, all protocols are allowed and all clients may be used. This can be modified to be more granular, either by configuring access rules in the services themselves, or by separating the networks with firewalls.
Typical clients used include Oracle Connector for Outlook, Mozilla Thunderbird, Oracle Web Conferencing, the Oracle Calendar Web client, Oracle Files and the Oracle Calendar desktop clients.
External Traffic
Externally, only a few encrypted, hardened and monitored services are exposed. HTTPS and SMTP are the only services typically available from the outside world, and these may be proxied accordingly.
Users who access Oracle Collaboration Suite from outside are generally relegated to the Oracle Calendar Web client and Oracle Web Mail over HTTPS.
SMTP is proxied though a mail relay and accepts e-mails from the outside world.
This section summarizes the issues to consider when evaluating an installation site. You should investigate these issues, then keep them in mind when reading through the detailed questions at the end of this chapter.
To meet your organization's required access options, start by asking the following questions.
Which Oracle Collaboration Suite components and network services will be used?
Choose the components of Oracle Collaboration Suite that you need, and consider which network services are necessary. For example, if you install the Email component, you may want it to be accessible from anywhere in the world through HTTPS. Generally, the three most important Oracle Collaboration Suite network services are reverse proxy, DNS and mail relay.
Where should these be accessible from?
For example, if Oracle Calendar is installed, will it be accessible externally as well as internally?
Do your plans fit into your organization's security model?
Before creating an elaborate deployment plan for Oracle Collaboration Suite, make sure you know your organization's security model, if there is one. For instance, some organizations may not allow DMZs or external access to e-mail.
What are the existing network services you are going to be relying on?
It is practical to make use of existing network services.
What's the configurability of these services? Can they be changed easily to suit Oracle Collaboration Suite?
Check how flexible your existing network implementation is.
What is the size of the current network, if there is one?
Find out what sort of upgrades and additions, if any, will have to be made to the network to accommodate Oracle Collaboration Suite.
How many users will there be?
This is a primary concern in determining the type of deployment you need. See Chapter 4, "Oracle Collaboration Suite Deployment Examples" for more information.
What is your budget?
Cost is obviously always an important consideration in any network installation.
Answers to the preceding questions will greatly help you to evaluate:
Which Oracle Collaboration Suite and network components need to be deployed
How many servers they will be deployed across
Where they will need to be deployed
How they will need to be configured
This section provides the following detailed questions you should ask about an existing network before deploying Oracle Collaboration Suite.
What kind of network/security policies does your organization have?
Does your organization use Network Address Translation (NAT) to abstract its network?
Has your organization implemented load balancing and reverse proxy?
Does your organization use hardware encryption acceleration?
Does your organization want to expose IMAP to the rest of the world?
Will your organization want Web Conferencing to be available through the Internet?
What services might your organization want to deploy for the first time, or upgrade?
What kind of network/security policies does your organization have?
Any existing policies will have to be adhered to when installing Oracle Collaboration Suite (unless your organization is willing to re-create its policies on short notice). This is likely to affect:
What services can be used
Where services can be exposed; that is, internally or externally.
Whether services need to be protected with SSL. If the answer to this is yes, it is a good idea to get SSL certificates early on in the process.
Does your organization have a DMZ, and if so, what kind?
This is crucial to the design and planning of your architecture, as it determines where components need to be placed, depending on how they are to be accessed.
If there is a DMZ:
How is it used for external access?
How is it used for internal access?
Are DNS (Domain Name Server) servers used? If so, consider the following issues.
Often, two DNS servers ("split DNS") are used, which helps separate internal from external traffic. This makes internal traffic more secure. Internal traffic might include access to printers or other material not to be made public.
DNS servers can be separated onto separate networks; for example, one in the DMZ and one in the internal network.
You can configure BIND (or whatever DNS server you are using) to respond to DNS requests differently, depending on where the request is originating.
DNS services can be further fortified when combined with NAT.
Having two DNS servers is more secure than just one. In either case, clients would connect to either an external or internal IP address for the same host name, depending on where the connection originates, and client access would be properly routed by DNS connectivity.
|
Note: For more information, see "What is your organization's existing DNS strategy?" later in this chapter. |
Does your organization use Network Address Translation (NAT) to abstract its network?
Generally, organizations set up NAT to translate internal addresses into public routable addresses. The translation takes place at the firewall and protects internal addresses from external tracing or "routing."
NAT has a large and beneficial impact on naming services; external IP addresses in DNS can be mapped to virtual addresses as configured in Collaboration Suite.
|
Note: When you install a middle tier, it "absorbs" the name of the server on which it is installed. You must configure external IPs on your DNS server, then configure Oracle Collaboration Suite to use the appropriate virtual addresses instead of the original server name. |
What is your organization's existing DNS strategy?
Your organization's existing DNS strategy is crucial to planning the access options for your Oracle Collaboration Suite installation. Together with NAT, DNS regulates how protocols are routed from users to the Oracle Collaboration Suite installation. There are two basic DNS strategies to consider:
Split DNS means that there is more than one naming service for a domain; generally one for inside the organization and one for outside. In Oracle Collaboration Suite, HTTP services are very domain-name specific, and in fact are mostly accessed through Single Sign-On. Oracle Collaboration Suite can only answer on one host name / domain name, so it is convenient to be able to map this to internal or external IPs as needed.
Ideally, you can have the same Oracle Collaboration Suite installation serving both internal and external requests. However, you don't necessarily want internal users having to access the instance from outside. Therefore, you use NAT with the Oracle Collaboration Suite servers so that:
Internal, non-routable addresses are mapped to external routable addresses.
Internal addresses are mapped to other internal addresses, if necessary.
You should configure the respective DNS servers to return the appropriate IP addresses for NAT, depending on whether the requests originate internally or externally.
Split DNS configurations are common and should be anticipated when designing the virtual host names for services prior to installation.
Configuring a single DNS instance is more difficult. Requests for Single Sign-On have to resolve both internally and externally.
Although configuring single DNS for a small company is less complex, it is not the most secure configuration, and in fact can expose crucial information about your network if not done properly.
Has your organization implemented load balancing and reverse proxy?
The use of load balancers and reverse proxy is an important strategy in securing your Oracle Collaboration Suite installation. With load balancing and reverse proxy, you can abstract the routing and addressing of HTTP/HTTPS traffic so that Oracle Collaboration Suite servers are not directly exposed to external users.
If your organization uses existing hardware and a switching strategy, try evaluating whether or not Oracle Collaboration Suite can be integrated into this.
The use of content switches as load balancers is recommended. Content switches can host virtual IP addresses and spread the load over multiple servers, particularly for middle tier services. Traffic can be redirected based on protocols such as HTTP, HTTPS, SMTP and so on.
If your organization currently has host names for its current services running on virtual devices, then migration will be much, much easier. In fact, it is always a good idea to identify virtual services names early in the process. Embed them in documentation and get SSL certificates early if they are needed. It is also a good idea to start setting up DNS and MX records (to map domain names to mail servers) early.
Does your organization use hardware encryption acceleration?
If you are planning on using the Secure Sockets Layer (SSL) protocol to encrypt communications, it is an excellent idea to make use of SSL accelerators to optimize performance. SSL processing is a CPU-intensive task that can greatly reduce CPU performance. This is best off-loaded to hardware devices designed for this purpose.
You should consider using SSL to encrypt external access to Oracle Collaboration Suite.
Does your organization have an SMTP mail relay?
Relay services are important for filtering, limiting and routing SMTP traffic. They can be used to protect Oracle Collaboration Suite instances from external abuse and unnecessary load.
Most organizations have an existing SMTP mail relay (or Mail Transport Agent), ideally with spam services implemented on it. Take note of what kind of limitations the relay has, such as:
Attachment size
Throughput throttling
Retry count
Evaluate whether or not these limitations are still realistic for your organization, and keep them in mind as you start to deploy Oracle Collaboration Suite.
It is a good strategy for many deployments to use programs such as these to handle and filter e-mail before forwarding it to the Oracle Collaboration Suite mail relay, which can reside behind a firewall or in a DMZ.
Does your organization want to expose IMAP to the rest of the world?
Many organizations will choose not to provide IMAP access directly over the internet, as they would feel overly exposed from a security standpoint. If you decide to provide IMAP access across the internet (without the additional security of a VPN infrastructure, for instance), Oracle Corporation strongly recommends implementing SSL for those IMAP services.
Is filtering installed for spam and viruses?
For the judicious use of valuable database storage, avoid saving unnecessary information such as e-mail spam. To protect the integrity of the network, viruses (often linked directly to spam) must also be blocked. There are a number of methods of filtering out these unwanted communications, including:
Use of milters: If a milter is installed, you may have to configure a server-side rule to remove flagged spam. If so, this may impact the server configuration and tuning process. Alternatively, you can use a third-party service to catch and delete spam. You should also evaluate whether there will be other input that you will have to accommodate. Ideally, you want to remove spam before it reaches the relay. The open source Postfix mail relay has a built-in spam tagger.
Server-side configuration: Like virtually any network traffic filtering, mail filtering can be configured directly on the server. Make sure you account for anything else that this configuration needs to be integrated with.
Will your organization want Web Conferencing to be available through the Internet?
The best way to make Web Conferencing available externally is to install it on its own server in a DMZ. This allows direct connections from the outside world for consoles, while reducing the load on small instances by dedicating Web Conferencing, a relatively high-load service, to its own box.
If Web Conferencing cannot be installed on its own server, the Web Conferencing server must still be available directly to clients, and not put behind a proxy server, for example (although NAT is supported). Web Conferencing clients first attempt to connect directly to the Web Conferencing servers, and then attempt to connect directly to the Oracle HTTP Server. Oracle HTTP Server and Oracle Web Cache cannot share the same IP address/port combination, so an organization may choose to deploy a second IP address for Web Conferencing traffic (also on ports 80/443).
Another issue to consider is how to manage using Web Cache and Web conferencing on the same middle tier. This is further addressed in Chapter 3, "Oracle Collaboration Suite Architecture Planning".
What services might your organization want to deploy for the first time, or upgrade?
It is possible that in the process of deploying Oracle Collaboration Suite, your organization may want to either implement services for the first time (such as reverse proxy, for example), or upgrade existing services (such as a mail relay).
