- Shopping Bag ( 0 items )
Solutions in this chapter:
* NetWeaver Web Application Server
* ABAP WEB AS 7.0
* J2EE WEB AS 7.0
* Backend UNIX/Oracle
* Governance, Risk, and Compliance (GRC)
When you consider the changes in SAP over the years, it's an evolution that is both amazing and inspiring. The vision of R/3 back in 1993 compared to where it is today, 15 years later, highlights its initial purpose. That purpose was to enable business to be more efficient, effective, and integrated. Those of us that studied process engineering and realized that the decentralized information technology (IT) culture and islands of automation we had in the 1980s and early 1990s were ineffective in helping business evolve, understood this need for an integrated enterprise solution.
Rudy Puryear of Accenture Consulting discusses the evolution of IT systems from the 1970s to today. He describes three phases of an electronically driven economy. These phases are about how organizations develop and execute business strategy enabled by IT. The first era was data processing, next came information systems, and finally knowledge management. One sees how this evolution aligns with SAP's continuous improvement program. The desired outcome for IT to improve business efficiency has stayed consistent through the years. However, the delivery of value-producing systems has not been easy to achieve until we finally reached this knowledge management era. The state of art at the time R/3 was being developed was not in keeping with that early vision.
Now, we fast forward to today and can see that our vision goes beyond enabling business and sees IT as an almost equal partner in effecting business efficiency. Today's worker is now a knowledge worker enabled by Web-based flexible tools and technologies. These tools provide nearly instant information about the business problems they are working with. But with the incredible efficiency SAP can provide comes a heavy burden on infrastructure complexity. The systems requirements for SAP are significant in terms of IT architecture, development architecture, and security infrastructure. In fact, I would maintain that embedded into every aspect of the infrastructure is now a component of security specification that must be addressed. Unfortunately, we still see many occasions where security is the appendix of the infrastructure plan. Security is often relegated to an after-thought that only gets emergency attention when an event occurs, a question of senior management is asked, or an audit drives a specific change. It is the rare organization that has an embedded active security-thinking culture.
Security infrastructure as an embedded part of the IT culture has yet to be recognized in the mainstream. However, when you consider the initiatives being addressed in corporations, institutions, and governments throughout the world, you begin to understand the strategic intent in evolving security. In nearly every conference on technology in the SAP and out of the SAP space there is a topic on security. And, now, SAP NetWeaver technology has evolved to include the major SAP components necessary to implement the full life cycle of security infrastructure. While IT enables business, security enables IT, and hence security is the underlying foundation to the business enablement.
With IT organizations yet to adapt to this mind-set, the challenges are even greater. Most IT organizations are classically stove-piped and hence the skills and training associated with these stovepipes are yet to evolve. Even worse, often an organization creates project teams that may tax the stove-piped security group with a part-time representative. When I speak with young engineers across the organization, however, they seem to realize the change that's happening and are struggling to help their leaders make the right investments and reorganize to face the change. I challenge management to bring these facets out in the open and create enabling organizations that put the security mind-set at the forefront. It's no longer a cliché to say that security is everyone's responsibility. SAP has laid a foundation for this. In each aspect of SAP's NetWeaver use-case scenarios lies a security layer. SAP describes these as usage types, which determine the intended purpose of a system or sub-system. They are available by installing and configuring collections of software components.
Figure 1.1 presents NetWeaver as a collection of components that meet different needs up and down the integration stack. It is important to recognize that today SAP NetWeaver is more than just a collection of components; it is an open technology platform which offers a comprehensive set of technologic capabilities that are natively integrated to support the needs of IT organizations worldwide. By reviewing the full gamut of capabilities one arrives at IT Scenarios and IT Practices that I refer to as use-cases.
IT Scenarios identify how one uses SAP NetWeaver to solve specific business problems. This is accomplished through deployment of the integrated IT scenarios in a way that does not disrupt existing business operations. IT practices look at the overall SAP NetWeaver platform as a strategic investment. One views the usage framework vertically and determines the options to focus on critical business issues rather then specific business problems addressed by tactical scenarios. This flexibility is the power of SAP NetWeaver.
SAP recommends that each practice be broken into one or multiple IT scenarios, providing organizations with a process-oriented approach to making best use of NetWeaver. By implementing IT scenarios, customers can adopt core functionality of SAP NetWeaver in incremental phases. The aim of IT scenarios is to help customers, partners, and independent software vendors (ISVs) install and operate SAP NetWeaver, to run business applications (custom-built and packaged applications), or to implement a defined IT goal like migrating to the services architecture. Focusing on the flow of activities rather than on the nature of the involved components, IT scenarios are collections aimed at resolving specific business area challenges.
The best way to see these IT practices and IT scenarios is with the SAP NetWeaver Technology Map.
The SAP NetWeaver Technology Map
In Figure 1.1, each IT practice is on the left, with its associated IT scenarios to the right. Usage types describe how installations of SAP NetWeaver are used, and which capabilities each offers to the overall IT landscape. By providing installation and basic configuration support for SAP NetWeaver systems, usage types provide the groundwork to run IT and business scenarios. Usage types make system landscape planning easier by determining how capabilities provided by SAP NetWeaver can be deployed and activated in a SAP NetWeaver system. In addition, configuration will be simplified by offering configuration templates for usage types and IT scenarios. Usage types were introduced with SAP NetWeaver 7.0. Each scenario or practice has a security implication. Each instantiation comes with its own unique set of questions, technologies, and considerations for implementation and architecture.
As an organization implements a new component or scenario, the development cycle used to design, create, test, and deploy must adopt their design and testing methodology to ensure compliance. There are a host of tools and processes available for this. This book, then, is to be a model for highlighting the SAP technologies available for implementing and institutionalizing security into the technology plans and implementations throughout the industry.
Security can no longer be the afterthought for implementations. I contend that as an afterthought, it is more costly to implement and retrofit. But as a key component in the early planning of any implementation security, security considerations are an equal partner in the design. A simple example of this shift is the following. Let's take a mythical company, Superior Marbles Inc. Superior Marbles has successfully deployed SAP and is using the system to manage its assets. A key aspect to many assets in a firm is location. And, with assets that are used by the average worker, tracking can be quite difficult. Every two or three years an asset such as a PC or cell phone may need to be replaced or upgraded. Also, work or home office locations for these devices must be tracked. Finally, when an employee leaves of the assets must be collected and accounted for. So, in this example, let us consider the Superior Marbles sales team. The sales force often has a personal data assistant (PDA), a laptop, a printer, and so on. So in a firm with 50 sales people we are quickly dealing with at least 150 line items to track.
The capital acquisition is an easy entry into SAP by the purchasing/receiving organizations, but when the asset is delivered it is no longer easy to track. Typically, inside SAP the tracking is at a cost center/departmental level. But, with a useful kiosk through the Web, enabling the sales team to self manage the assets would prove extremely useful. So, an extension from the SAP database to an applet available to end-users (the sales people) over the Web will be our project. Many technologies are in play for this project. How will they securely log in? What will be presented to them and how will the data exchange occur back into SAP?
One can envision tackling the project via the typical analysis/requirements development process. But where are the security considerations determined and discussed with the user? They often aren't. It's left to IT network people, IT architects, and the developers to build on the basic requirements and ensure security. Even worse, there are times when audit concerns are missed until an actual audit, which can reveal additional shortcomings. So, the corrected approach is to address with the users the complete life cycle for the application and secure the application and its data. Having proper requirements specifications for the development team removes the ambiguity. And, better still, during audits these specifications are part of the development record and often this kind of data serves an important purpose as part of the catalog of documents used in building the application. So, then, what are the technologies that one must be concerned with in deploying an application within the SAP framework?
There are three key underlying concepts to all of the security infrastructure layers. These are data integrity, user access, and user authorization. Simply put, how is the data in the system ensured, how do users gain access, and what can users do with that access? The concepts associated with securing the infrastructure and applications will address these three key areas.
The scope of this discussion will be focused on four overlying security technologies that specifically encompass SAP. There are a host of certified for NetWeaver non-SAP, such as Microsoft's BizTalk framework that complement SAP; however, these are out of scope for this book. It is hoped that through a study of the components and considerations of the SAP technologies extension to the non-SAP is possible. The same considerations will be consistent across the infrastructure independent of the specific technology. Thus, we will focus on both ABAP and Java Web Application Server 7.0, Governance, Risk and Compliance (GRC) and the typical backend infrastructure foundations UNIx/Oracle. We do not mean to exclude specific, relevant technologies such as SQL Server or Linux, but we believe extensibility is appropriate and we also find in the main that UNIx/Oracle still appear to have the lion's share of systems in an SAP installation. Thus, if you are working in a heterogeneous landscape the concepts outlined here will still apply.
NetWeaver Web Application Server
SAP NetWeaver 7.0 provides an open integration and application platform and facilitates the implementation of Enterprise Services Architecture (see Figure 1.2). Both ABAP and Java are fully supported in SAP. Sizing considerations and architecture plans should be considered in order to determine the best model for implementing these stacks. While integrated ABAP/JAVA Web AS on the same server is possible, it is recommended to have separate hardware (application server) in either virtual or physical modes for the ABAP Web AS and the JAVA Web AS. Highlighted in the following sections is an overview of the J2EE Web AS and the ABAP Web AS feature, functions, and security insights.
Excerpted from SAP Security Configuration and Deployment by Joey Hirao Jeanmarie Hirao Mimi Choi Perry Cox Steven L. Passer Copyright © 2009 by Elsevier, Inc.. Excerpted by permission of Syngress Publishing, Inc.. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.