ITむンフラストラクチャを保護する方法7぀の基本的なヒント

デヌタ挏えいに関する情報がニュヌスに次第に登堎し、倧䌁業はセキュリティの匷化に膚倧な量を費やしおいたす。 IDCのコンサルティング組織が指摘しおいるように、2020幎たでに、ITセキュリティぞの䞖界的な支出は1,000億ドルを超えたす。



ただし、安党なITむンフラストラクチャを構築するために倚額の費甚をかける必芁はありたせん 。 たずえば、Linuxシステムには保護メカニズムが組み蟌たれおおり、適切に構成されおいれば、OSおよびネットワヌクに察する最も䞀般的なタむプの攻撃を反映できたす。



この蚘事では、ITむンフラストラクチャをハッキングしお情報を危険にさらす可胜性を枛らすいく぀かの基本的なヒントを芋おいきたす。 投皿の䟋はLinuxベヌスのシステム甚に提䟛されおいたすが、説明されおいるプラ​​クティスの䞀郚は他のOSにも適甚できたす。





/ Flickr / cezary borysiuk / PD



1.最新のセキュリティ曎新プログラムをむンストヌルしたす



この点は非垞に明癜であり、アプリケヌションの定期的な曎新の重芁性は以前に曞かれおいたすが、残念ながら、それはただ関連性を倱わない。 OpenSSL- Heartbleed CVE-2014-0160の脆匱性状況をご芧ください。



攻撃者がサヌバヌの秘密鍵を抜出し、それを䜿甚しお送信されたトラフィックを埩号化できるようにしたす。 2014幎に゚ラヌ情報が公開された時点で、脆匱なサむトの数は合蚈50䞇でしたが、同時にGoogleの開発者BodoMöllerずAdam Langleyは脆匱性を修正するパッチを準備したした 。 ただし、党員がアップデヌトをむンストヌルしたわけではなく、Shodanによるず 、Heartbleedは20䞇近くのWebサむトの圱響を受けおいたす。



システムを最新の状態に保぀ために、OSの自動曎新セキュリティを蚭定するこずをお勧めしたす。 ほずんどのベンダヌは、パッチを自動的にむンストヌルするツヌルを提䟛しおいたす。 たずえば、Debianには無人アップグレヌドナヌティリティがあり、Red Hat ベヌスのシステムにはAutoUpdatesがありたす。 Yum-cronはCentOSで、 dnf-automaticはFedoraで利甚できたす。



パッケヌゞマネヌゞャヌを䜿甚しおアップグレヌドするこずもできたす。 たずえば、 Debianの堎合 



apt-get update && apt-get upgrade
      
      





パッチの自動むンストヌルには欠点がありたす。たずえば、曎新によりシステムがクラッシュする堎合がありたす。 したがっお、運甚環境に曎新プログラムをむンストヌルする前に、サンドボックス内の゜フトりェアの予備テストを実斜する䟡倀がありたす。



サヌビスパックの開発者は、゜フトりェア補品がシステムに朜圚的に危険な倉曎を加えないようにしたすが、アプリケヌションずサヌビスの可胜な組み合わせをすべおテストするこずはできたせん。 たずえば、最近リリヌスされたWindows 10甚のパッチKB4041676は、䞀郚のナヌザヌのコンピュヌタヌを無限の再起動サむクルに送り、「死のブルヌスクリヌン」を生成したした。



同時に、アップグレヌド埌のシステムの䞀郚は、関連するすべおのプロセスが再起動されるたで、䟝然ずしお゚クスプロむトに察しお脆匱です。 たずえば、2014幎にOpenSSLは、攻撃者がDDoS攻撃を行うこずを可胜にするいく぀かの脆匱性を発芋したした 。 Debianバヌゞョン1.0.1e-2 + deb7u10では閉じられおいたしたが、それらを有効にするには、OpenSSLに関連するすべおのアプリケヌションを再起動する必芁がありたした。 再起動が必芁なプログラムを怜玢するために、コミュニティはcheckrestartおよびneeds- restarting ナヌティリティを 開発し たした 。



2.セキュリティ拡匵機胜を有効にしたす



珟代のシステムでは、さたざたなナヌザヌが所有する倚数のデヌモンずプログラムが回転しおいたす。 ボランタリヌず呌ばれる埓来のUnixモデルDAC-任意アクセス制埡は、アクセス暩を割り圓おるずきに、ナヌザヌ、ナヌザヌグルヌプ、およびアプリケヌション管理プロセスを耇雑にする他の3぀のパラメヌタヌで動䜜したす。



セキュリティポリシヌを蚭定するためのより倚くのオプションを管理者に提䟛するために、MAC必須アクセス制埡モデル、぀たり匷制アクセス制埡に基づいおセキュリティ拡匵機胜が開発されたした。 これらは埓来のモデルを補完し、すべおのプロセスのセキュリティポリシヌを確立する機䌚を提䟛したす。 たずえば、指定されたポヌトでリッスンするようにWebサヌバヌを「泚文」するか、指定されたディレクトリからのみファむルを読み取れるようにしたす。



セキュリティアプリケヌションの䞭では、 SELinux、AppArmor、GrSecurity他にもありたす を区別できたす。それぞれに長所ず短所がありたす。 次に、SELinuxの機胜を簡単に怜蚌したす。これは最も安党でこのアプリケヌションは政府システムで䜿甚するために䜜成された、nixCraft Vivek Giteのシステム管理者および䜜成者ずしお、最も匷力なアクセス制埡メカニズムを備えおいたす。



3぀の動䜜モヌドがありたす。 匷制は、確立されたセキュリティポリシヌに違反するアクションをブロックするデフォルトモヌドです。 2番目のモヌド蚱可は、ログ内のすべおの違反をキャプチャしたすが、それらをブロックしたせん。 3番目の状態-無効-は、システムが無効であるこずを意味したす。



次のコマンドを蚘述するず、蚭定されおいるモヌドを確認できたす。



 $ /usr/sbin/getenforce
      
      





SELinuxを有効にするには、次のように入力したす Fedoraの堎合



 rpm -qa | grep selinux rpm -q policycoreutils rpm -qa | grep setroubleshoot #   
      
      





このナヌティリティは、いく぀かのアクセス制埡モデルを提䟛したす。



  1. Type Enforcement TEプラむマリアクセス制埡メカニズム。 柔軟ですが時間がかかりたす。 すべおのオブゞェクトずサブゞェクトには識別子が付いおおり、これらを䜿甚しおルヌルずポリシヌを割り圓おるこずができたす。
  2. 圹割ベヌスのアクセス制埡 RBACシステムには、1぀以䞊のドメむンタむプに関連付けられた圹割が割り圓おられたす。 それらのチャヌトはここで芋぀けるこずができたす 。
  3. マルチレベルセキュリティ MLSすべおのシステムオブゞェクトは特定のレベルのアクセスを受け取り、その機胜を制限したす。 そのレベルでは、サヌビスは情報の読み取りず曞き蟌みを行うこずができ、䞊のレベルでは曞き蟌みのみ、䞋のレベルでは読み取りのみが可胜です。 セキュリティレベルの図がここにありたす 。


SELinuxがむンフラストラクチャを保護する状況の䟋ずしお、構成゚ラヌが発生する堎合がありたす。 DNSサヌバヌは、サヌバヌ間でデヌタを耇補するずきに、ゟヌン転送ず呌ばれるものを実行するこずがよくありたす。 攻撃者はこの手順を䜿甚しお、誀った情報をサヌバヌにブロヌドキャストできたす。 FedoraでBINDを䜿甚する堎合、管理者が情報の亀換を蚱可するサヌバヌの範囲を制限し忘れおも、SELinuxポリシヌはレプリケヌション䞭のゟヌンファむルの倉曎を防ぎたす。



SELinuxでは、プロセスが他のプロセスで䜿甚されるファむルにアクセスするのをブロックするこずもできたす。 たずえば、攻撃者はSambaサヌバヌを危険にさらすこずはできず、それを介しお他のシステムMySQLデヌタベヌスなどのファむルを倉曎したす。



SELinuxが保護するその他のナヌザヌケヌスは、 ここから入手できたす 。 Debian で SELinuxをセットアップするための詳现なガむドず、Fedoraのガむドがここにありたす 。



3.アクセス暩を蚭定し、パスワヌドポリシヌを蚭定する



この点も非垞に明癜ですが、重芁ではなくなりたせん。 2015幎に2000人のオフィスワヌカヌを察象にむンタヌメディアが実斜した調査によるず、回答者の93が少なくずも1床は情報セキュリティ芁件を無芖したこずを認めたした。 同時に、IT業界の埓業員の67が、さたざたなアカりントのナヌザヌ名ずパスワヌドを同僚ず共有しおいるず答えおいたす。



脆匱で䞀般的なパスワヌドは、䌚瀟のむンフラストラクチャの「感染」の可胜性を高め、䞍適切に蚭定されたアクセス暩は組織のシステムの抜け穎を開きたす。 したがっお、サヌバヌに管理者ルヌトずしお接続するこずはお勧めしたせん 。 新しいナヌザヌを䜜成し、暩限を制限しおこのアカりントを操䜜し、sudoを䜿甚しお管理するこずをお勧めしたす。



Stack Exchangeの居䜏者が指摘しおいるように、このアプロヌチは攻撃者の生掻を困難にしたす。 ハッカヌは、SSHssh root @ $ IPを介しお接続芁求を送信するボットを䜿甚し、暙準の組み合わせ「root」たたは「password123」が最も䞀般的ですたたはブルヌトフォヌスを䜿甚しおパスワヌドを遞択できたす。 ルヌトアクセスを取埗できた堎合、システム党䜓で「無制限の電力」を取埗したす。



しかし、rootがSSH経由で接続できない堎合、ボットは最初にナヌザヌ名を掚枬する必芁があり、ハッキング手順が難しくなりたす。



DebianおよびUbuntuで新しいナヌザヌを䜜成するには、コン゜ヌルで次のコマンドを入力したす。



 adduser administrator
      
      





管理者フィヌルドは任意に倉曎できたす。 次に、パスワヌドが登録されたす。 パスワヌドデポでは 、8〜10文字の長さで、異なるレゞスタ、数字、特殊文字を䜿甚したパスワヌドを䜜成するこずをお勧めしたす。 Coding Horrorブログの著者であり、Stack OverflowおよびStack Exchangeプラットフォヌムの共同蚭立者であるゞェフアトりッドは、10文字以䞊のパスワヌドを䜿甚するず、 最も人気のあるリストに衚瀺される可胜性が80 枛少するこずに泚目しおいたす。



はい、耇雑で長いパスワヌドを䜜成する必芁があるこずはよく知られおいたすが、実際には、誰もがこの芏則に埓うわけではありたせん。 SplashDataチヌムは、2016幎に「統合」された䌁業埓業員のアカりントから500䞇を超えるパスワヌドを分析したした 。 研究者は、ほずんどのパスワヌドは完党に安党ではないず結論付けたした。 パスワヌド「123456」が最も䞀般的になり、「テスト」セット党䜓の4のアカりントで䜿甚されたした。 ほが同じ割合で入力されたパスワヌド「password」。



たた、北郚の他のナヌザヌの承認のためにデヌタを凊理する䟡倀がありたす。 脆匱なパスワヌドは、 John the ripperナヌティリティを䜿甚しお怜出できたす。 システムに「パスワヌドのない」ナヌザヌがいないこずを確認するには、このコマンドが圹立ちたす。



 awk -F: '($2 == "") {print}' /etc/shadow
      
      





パスワヌドの䜜成を必須手順にし、パスワヌドの有効期限を蚭定するには、pam_cracklib.soファむルの蚭定を倉曎したす。



 chage -M 60 -m 7 -W 7 UserName
      
      





pam_unix.soの叀いパスワヌドの再利甚を防ぎ、ログむン詊行回数に制限を蚭定したす。



耇数のアプリケヌションがあり、それぞれがさたざたな重芁な情報にアクセスできる堎合、別々のアカりントからそれらを起動しお、あるアプリケヌションから別のアプリケヌションのデヌタぞのアクセスをブロックする䟡倀がありたす。



アプリケヌションにメヌルサヌビスを埋め蟌むためのAPIを開発しおいるMailgunが指摘しおいるように、このアプロヌチの目暙は、ハッカヌがただシステムに䟵入できる堎合にハッカヌの「オプション」の数を枛らすこずです。 アプリケヌションのアクションのリストが必芁最小限に制限されおいる堎合、攻撃者は、たずえばアクセス暩を䞊げお重倧な損害を䞎えるこずができたせん。



適切なナヌザヌのすぐ䞋で開始されるように、サヌビスを「デモ」したす。 これを行うには2぀の方法がありたす。 1぀目は、OSスクリプト initたたはsystemd を䜿甚しおアプリケヌションを起動/停止し、監芖ツヌル monit を䜿甚しおクラッシュした堎合に再起動するこずです。 2番目のアプロヌチは、アプリケヌションを独自に管理するプロセス制埡システム Supervisord 、 s6 、 daemontools を䜿甚するこずです。





/ Flickr / reynermedia / CC



4.ファむアりォヌルのルヌルず䟋倖を構成する



最近、 systemdマネヌゞャヌに脆匱性 CVE-2017-15908 が発芋され、DDoS攻撃が可胜になりたした。 脆匱なシステムがハッカヌによっお制埡されおいるDNSサヌバヌにDNSク゚リを送信するず、systemdが無限ルヌプに入り、100のCPU負荷を匕き起こす特別なク゚リを返したした。



このタむプの攻撃から保護する1぀の方法は、ファむアりォヌルを構成するこずです。具䜓的には、この堎合、ファむアりォヌルはRFC 4034のセクション4で説明されおいるリ゜ヌスレコヌドを含む朜圚的に悪意のあるパケットをブロックするように指瀺されたす 。



䞀般に、倖郚アクセス甚に少数のサヌビスのみを開くず、「連絡先」の数が枛り、その結果、システムに䟵入する可胜性が䜎くなりたす。



ファむアりォヌルルヌルを蚭定するずき、Mailgunチヌムは次の原則に埓うこずを掚奚したす 。



  1. 新しいルヌルを蚭定する前に、既存のルヌルを削陀したす。
  2. デフォルトでは、着信トラフィックを凊理するには 、DROPパラメヌタヌを蚭定したす確立されたルヌルを満たさないトラフィックはスキップされたせん。 この埌、倖郚ネットワヌクぞのアクセスを埐々に「開く」こずができたす。
  3. むンタヌネット制埡メッセヌゞプロトコルICMPトラフィックを完党に制限しないでください。 ルヌタヌずホストはこれを䜿甚しお、サヌビスの可甚性、パケットサむズなどに関する重芁な情報を送信したす。StackExchangeで述べたように、ICMPは制限できたすが、これらの犁止の圢匏は䌚瀟のむンフラストラクチャによっお異なりたす。
  4. IPv6を䜿甚しおいない堎合、このトラフィックを制限したす。


これらすべおの掚奚事項を実装するために、Mailgunは構成甚の独自のスクリプトを䜜成したした 。 こちらで芋぀けるこずができたす。



5. SSH経由で安党に接続する



たず、信頌できるSSHキヌを生成したす。 これは、ssh-keygenを䜿甚しお実行できたす。



 ssh-keygen -t rsa -b 4096 -C foo@example.com
      
      





その埌、キヌが䟵害された堎合にキヌを保護するパスフレヌズを入力する必芁がありたす。 SSH接続を敎理するには、たずもな暙準構成のOpenSSHを䜿甚できたす。 OpenSSHパラメヌタに関する詳现情報は、MozillaのマニュアルたたはCentOS wikiペヌゞにありたす 。



私たちの偎では、暗号キヌのペアを䜿甚しおSSH経由でアクセスするこずをお勧めしたす。 2番目のキヌは、ブルヌトフォヌスによるハッキングを倧幅に耇雑にしたす。 前述のように、パスワヌドが長いほど信頌性が高くなり、SSHキヌの長さは、たずえば2048ビットになりたす。



これを行うには、新しいキヌを䜜成し、公開キヌをサヌバヌにアップロヌドしたす。 ロヌカルコンピュヌタヌから次のように入力したす。



 ssh-copy-id admin@1.1.1.1
      
      





adminをキヌの所有者の名前に、1.1.1.1をサヌバヌのIPアドレスに眮き換えたす。 接続を確認するには、再接続する必芁がありたす。



パスワヌドを入力するためのSSH接続を完党に無効にしお、党員がキヌを䜿甚できるようにするこずもできたす。 次に、/ etc / ssh / sshd_configファむルのPasswordAuthentificationパラメヌタヌの倀をnoずマヌクする必芁がありたす。



UbuntuたたはDebianでは、次のようになりたす。



 nano /etc/ssh/sshd_config ... PasswordAuthentication no
      
      





远加の接続セキュリティは2FA 二芁玠認蚌 を䜿甚しお実珟できるこずに泚意しおください。



6.暗号化を䜿甚する



䟵入者からむンフラストラクチャを保護するには、暗号化を䜿甚する必芁がありたす。 個人情報および資栌情報を暗号化せずに保存しないでください。 パスワヌドがGitHubのプラむベヌトリポゞトリにある堎合でも。 そのため、GitHubが䟵害された堎合にむンフラストラクチャを保護したす。これは、昚幎䞀幎で既に発生しおいたす。 攻撃者は、他のサヌビスをハッキングした結果ずしおコンパむルされたパスワヌドず電子メヌルアドレスのリストを䜿甚しお、いく぀かのナヌザヌアカりントを䟵害し、䌁業情報にアクセスしたした。



暗号化甚のツヌルたたはラむブラリを遞択する堎合、MailgunチヌムずStack Exchangeの居䜏者は、次のルヌルに埓うこずをお勧めしたす。



  1. 最新の察称暗号を䜿甚したす。最も䞀般的なオプションは AESずSalsa20NaClです。
  2. MAC メッセヌゞ認蚌コヌドを䜿甚しお、デヌタ゜ヌスの敎合性ず認蚌を制埡したす。 適切なオプションは、 HMAC-SHA-512たたはPoly1305です。
  3. キヌずタむムコヌドを生成するための高品質なランダマむザヌに泚意しおください。 たずえば、 / dev / urandom 。
  4. ツヌルがパスフレヌズで機胜する堎合は、 KDFを䜿甚しおいるこずを確認しおください。


察応するスレッドのStack Exchangeで、ナヌザヌは暗号化システムを䜜成するための倚くのツヌルentlibやBouncy Castleなど を提䟛したす。 本圓に必芁な堎合は、独自のナヌティリティを䜜成できたすが、 RedditずQuoraの䜏民は、このアプロヌチはハッキングのリスクを高めるだけだず蚀いたす。 Stack Exchangeで述べたように、ほずんどの堎合、自家補の暗号は 、 ポリアルファベティック暗号および眮換暗号を 解読するためのハッカヌツヌルによる攻撃にほずんど耐えたせん。



さらに、暗号化システムの操䜜を開始する前に、いく぀かの゜ヌスを提䟛しおいたす。 1぀目はCrypto101コヌスで、スタヌトアップ向けのセキュリティトレヌニング䌚瀟であるプリンシパルのディレクタヌであるLaurens Van Houtvenが教えおいたす。 2番目のリ゜ヌスであるmatasano暗号チャレンゞには、実際の暗号に察する攻撃を瀺す48の挔習が含たれおいたす。 著者は、このトピックに関する本を読むよりも、暗号の原理を研究するためのより効果的な方法であるず䞻匵しおいたす。



7.バックアップを定期的に䜜成しお確認する



バックアップの問題は、䞊蚘のトピックの䞀般的なテヌマから少し倖れおいたすが、むンフラストラクチャのセキュリティを確保するためにも重芁です。 繰り返しになりたすが、このトピックは倚くの資料で「噛み砕かれおいたす」が、倧䌁業でさえ間違いを犯しおいるため、繰り返す必芁があるず考えおいたす。



最近の䟋から、オランダのシステム管理者によるGitLabナヌザヌのプロゞェクトのドキュメントずコヌドを倉曎する芁求を䌎うデヌタベヌスの䞀郚の削陀。 その埌、同瀟は、実装された5぀のバックアップストレヌゞシステムのいずれも情報の埩元に圹立たなかったず指摘したした。



したがっお、バックアップを䜜成し、ビゞネスの芁件を考慮しお、可胜な限り頻繁に準備を確認するこずは圓然のこずです。 たずえば、Webアプリケヌション開発䌚瀟であるNeon Rainの゚ンゞニアは、週に1回ファむルをバックアップし、毎晩デヌタベヌスをバックアップしたす。 Cloud Academiesでデヌタベヌスの毎日のバックアップコピヌを䜜成したす 。 たずえば、Chalvington Groupのバックアップのチェックに関しおは、回埩の可胜性が毎朝評䟡されたす。



䞀般に、1日に1回バックアップするのが通垞の方法です。 䞻なこずは、バックアップを䜿甚しおサヌバヌぞのアクセスを制限するこずです。匕き続きアクセスするアカりントの堎合、メむンむンフラストラクチャで䜿甚されるものずは異なる承認メカニズムを䜿甚する䟡倀がありたす。



独自のバックアップむンフラストラクチャを線成したくない堎合は、バックアップコピヌの保存を担圓するサヌドパヌティベンダヌにこのタスクを転送するこずをお勧めしたす。 たずえば、1cloudでは、1日に1回バックアップし、クラむアントはコピヌに必芁なストレヌゞ時間7、14、21、たたは28日を遞択したす。



䞊蚘のツヌルず蚭定は、システムを保護するのに圹立ちたす。 はい、あらゆる皮類の攻撃からITむンフラストラクチャを100保護するこずは物理的に䞍可胜ですが、クラッカヌの寿呜を耇雑にし、朜圚的な゚クスプロむトの数を制限するこずは可胜です。 泚意、泚意、および泚意を払えば、重芁な決定を䞋し、保護察策を講じるのに必芁な時間を埗るこずができたす。






䌁業ブログ1cloudのトピックに関する3぀の資料






All Articles