Skip to main content

Sudahkah Anda membuat Akses aman ke data center untuk partner / supplier Anda ?

Partner access: Balancing security and availability
Whenever outsiders -- partners or vendors -- are granted access to corporate systems, another wrinkle is added to the already complicated paradigm that is enterprise identity and access management. An organization needs to make sure outsiders have access to key systems and data so business runs smoothly and profitably. But, at the same time, care must be taken to ensure unwanted or hostile intruders aren't gaining malicious access into corporate systems.
In reality, secure partner access is just an extension of existing access management for mobile and remote employees -- but with a few twists. Employees are already enrolled in the organization's directory service, whether Active Directory, LDAP or some other system. They're company insiders who are already part of the network, not outsiders from another network with a different IT security set up.
So, how should an organization ensure secure access for partners and vendors, some of whom work so tightly within a company that they may almost be considered employees? Should their networks be treated as hostile connections that need to be strictly filtered, or should they be added to the standard directory service and treated like regular employees?
The answer lies somewhere between these two extremes. It depends on three factors: the type and amount of data the partner needs to access, the number of users the vendor needs to access that data and the risk level of the third party.
Before considering these factors though, it should be made clear that the decision ultimately should be driven by business requirements, not security requirements. Security requirements should be dictated by the business need, not the other way around. There is no one-size-fits-all approach to secure partner access. If the business needs it, then design the right level of security to be wrapped around it based on a thoroughrisk assessment of corporate partners.
Secure partner access approaches

There are many approaches to providing secure access to partners and vendors, from simple firewall rule exceptions to encrypted T1 lines andSSL VPN
 extranets. Here are some ways to choose the best method for securing access from partners and then best practices for implementing that solution.
The first step is to conduct a thorough risk assessment of the potential partner or vendor needing system access. This means assessing the third party the way you would assess your own company -- against your IT security policy. The obvious things to check are their security policies, access management systems, physical and personnel security, firewalls and security of IT infrastructure. This may require a visit to the partner's site to do a follow-up walkthrough.
This may seem burdensome, but remember, your security is linked to that of your partner. If there's a breach at your partner, and it involves your company's data, guess whose name gets in the headlines? The public -- and possibly lawyers -- don't distinguish between a company and its partner in such cases.
Next, review the risk assessment in light of the access required. These are the key questions: 
·         What type(s) of data does the partner need to access? 
·         Where does that data reside and on which systems? 
·         Which systems does the partner need to access and for what purpose? 
·         How often do they need access? Is it just for quarterly access to update software, for example, or daily access to update customer data feeds?
Partner access scenarios

The best way to illustrate best practices for secure partner access is through some examples. Here are five scenarios in order of ascending risk: a marketing company that needs access to analyze demographic data; a software vendor that needs to send periodic updates to update their software on a corporate system; a supplier that needs access to ship products; an offshore application development center and a contracted call center that needs full access to the customer database.
The marketing company analyzing demographic data is an example of a low-risk situation. Demographic data can't be tied to individual customers, so it can't be used for identity theft. Such data is usually used for market research or sales models. The best approach here, especially if the number of users at the vendor is small -- say, a few dozen -- is to provide limited VPN access. With SSL VPNs, like those offered by Aventail Corp., Juniper Networks Inc. and Cisco Systems Inc., the users are only allowed access to selected systems and data. In addition, access by SSL VPNs can be finely tuned by type of user and application.
A key difference between SSL VPNs and IPSec VPNs, the other type of VPN, is that an SSL VPN connects an individual user to a specific application, while an IPSec VPN connects a workstation to a network. SSL VPNs are Web-based, so they can be accessed from any browser, which means any desktop. IPSec VPNs can also be tuned to restrict users to specific applications and systems, but they offer more unrestricted access not required by users like those in our marketing company scenario.
Another popular product, similar to an SSL VPN, is Citrix Systems Inc.'s NetScaler, which also provides restricted access for remote users to specific applications through a Web browser. Both SSL VPNs and Citrix mesh well with Active Directory, allowing users from partners and vendors to be added with appropriate restrictions.
For more information:
The second scenario, a software vendor needing access to send periodic updates, can be handled a few different ways. The update can be retrieved from the vendor's Web site rather than granting the vendor system access. Other possibilities, particularly for upgrades to mainframe software, include encrypted batch feeds or the use of a secure file transfer product like Connect:Direct from Sterling Commerce. The Sterling line of products can also be used for regularly transferring other types of files securely to partners and vendors.
The third scenario, a supplier integrated into your company, hikes up the risk a notch. The supplier may need access to your inventory systems, but obviously not to customer data. This may lower the risk of identity theft, but not of physical theft. The best option may be an extranet with a secure connection, such as through an SSL VPN. IP filtering or firewall rules should also be used to prevent access of the extranet from a site other than the vendor's. Otherwise, a malicious employee at the vendor could access the site from their home and conduct unauthorized transactions, at the least.
The fourth scenario is similar to the third in that offshore developers, like suppliers, need access only to specific systems; in this case, development environments and application code. But the developers may be halfway around the world in India or China. This means that they have to connect from their own far-flung networks. The connections to your network should be through a segregated network segment on its own firewalls.
As for the fifth scenario, a third-party call center, the connection -- whether through regular TCP/IP or a T1 line -- should be both dedicated and encrypted. In this high-risk situation, where employees of a third party are dipping directly into your sensitive customer data, a multi-layered approach should be used. An SSL VPN combined with IP filtering and firewall rules limit access from the vendor. Two-factor authentication with one-time password (OTP) tokens is a thought, but the high turnover at many call centers makes this option a management nightmare. The options, of course, also depend on the type of application call center employees need to access, whether it's a mainframe green screen or Web-based, for example. Either way, VPN options, both SSL and IPSec, are available.
Finally, as with access for your own employees, all vendor and partner access needs to be logged, audited and regularly pruned to remove inactive users. From this perspective, secure partner access is no different than regular employee access. It's nothing more than creative use of VPNs, dedicated connections, IP filtering and encrypted connections.

About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and the author of The Little Black Book of Computer Security available on Amazon. He hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at


Popular posts from this blog

Timer AC bergantian

Bagaimana sich prinsip kerja AC yang bergantian? Seperti yang terangkai pada ACPDB, yang kita butuhkan adalah 1 buah timer dan 2 buah kontaktor. Pada dasarnya rangkaiannya adalah seperti gambar diatas. Seperti kita ketahui, timer dan kontaktor akan bekerja apabila mendapatkan catuan 220 V. Pada timer catuan bisa dikoneksikan di lubang “L” dan “N”, sedang pada kontaktor dilubang “A1” dan “A2”. Itulah kenapa pada saat mati listrik komponen2 tersebut tidak bekerja. Timer berfungsi sebagai switch dari 2-1 atau 2-3 dan lubang “2” sebagai sumber yang dialiri arus listrik. Sesuai namanya alat ini akan bergantian dari 2-1 atau 2-3 berdasarkan waktu yang sudah kita atur pada sirip biru. Satu sirip merepresentasikan 30 menit. Sedang pada kontaktor untuk tipe Telemecanique, sumbu-sumbu saklarnya adalah 1-2, 3-4, 5-6, NO-NO, NC-NC.  Jika “A1” dan “A2” tidak dicatu maka 1-2 (open), 3-4 (open), 5-6 (open), NO-NO (open), NC-NC (close/terhubung). Dan bila “A1” dan “A2” dicatu  maka 1-2 (close), 3-4 (clo…

Contoh Panduan Standarisasi Area Data Center

Berikut adalah contoh Panduan Standarisasi Area Data Center

PANDUAN - IK Standarisasi Area Data Center Article Number: 49 | Rating: Unrated | Last Updated: Mon, Nov 25, 2013 at 2:13 PM BAB I KEBIJAKAN
1.1.Area Data Center
Areadata center termasuk aset vital perusahaan dan diperlakukan sesuai dengan persyaratan yang telah ditetapkan dalam Sistem Manajemen Pengamanan Perusahaan.

Seksi Jaringan bertanggungjawab terhadap pengamanan fisik dan logik. sedangkan fungsi Sekuriti terhadap pengamanan fisik.

1.2.Pertimbangan Dalam Hal Penentuan Lokasi Area Data Center
Beberapa pertimbangan yang harus ada dalam menentukan lokasi ruang data center, yaitu :

1.Memungkinkan untuk pengembangan yang memadai, misalnya mempertimbangkan pengembangan untuk jangka waktu 5 (lima) tahun ke depan.
2.Mempertimbangkan ruang yang tidak "terlalu” banyak dilalui untuk operasional lain, namun tetap dapat dijangkau dengan mudah.
3.Memperhatikan aspek keamanan dan keselamatan pekerja.
4.Memenuhi persyaratan sebagaimana yang …

Mendesigns dan Menghitung UPS untuk Data Center

Mendesigns dan Menghitung UPS untuk Data Center UPS dan data center mungkin bisa di sebut sayur tanpa garam, hambar jika tidak saling melengkapi. 
Tapi untuk menentukan kebutuhan akan UPS data centerperlu perhitungan yang matang agar UPS dan server tetap awet dan selalu ON 24 jam. banyak sekali jenis UPS dan daya yang di tawarkan. Kita harus menghitung kebutuhan beban keseluruhan server agar ketika listrik down UPS dapat menghandle beberapa detik untuk listrik pindah ke genset begitu pula sebaliknya, Oke untuk menentukan itu semua tentukan dulu jenis UPS yang akan anda gunakan.
Oke kita sedikit belajar dulu tentang UPS :)
PRINSIP KERJA UPS Setiap PC membutuhkan daya listrik. Apabila aliran listrik (main power) terputus, PC akan mati (tidak berfungsi). Fungsi dasar UPS (Uninterruptible Power Supply) adalah menyediakan suplai listrik SEMENTARA ke beban (PC) tanpa terputus pada saat main power tidak bekerja agar seluruh proses dapat dihentikan dengan benar, seluruh data dapat disimpan den…