インフラエンジニア・書籍学習まとめ

こんにちはよしときです。 本日はインフラについて勉強したことをまとめてみたいと思います。使用した教科書はこちら   それでは第一章から見ていきます。  

第一章 インフラエンジニアの仕事

まず、始めにインフラエンジニアとはどんな仕事か、というところから始まります。 インフラエンジニアの仕事は大きく分けて三つあり、
  • インフラ設計
  • インフラ構築
  • インフラ運用
に分けられます。 さらにITインフラを構成する要素として
  • ファシリティ
  • サーバ・ストレージ
  • ネットワーク
が挙げられます。 これらの用語に加え技術者、選定者としてのインフラエンジニアのするべきことを簡易的に挙げていきます。 まず、技術者としてのインフラエンジニアの側面として
  • サーバハードウェア
  • サーバOS
  • ストレージ
  • ネットワーク設計と構築
  • ネットワーク機器
を押さえておくべきだと挙げています。 次に 選定者としてのインフラエンジニアの側面として
  • システム構成
  • サーバスペック選定
  • ネットワーク構成
  • データベース設計
  • 運用体制
  • 社内での責任範囲
が挙げられています。 上記の内容としてはかるく触れる程度で、順次章ごとに説明していきます。  

第二章 サーバ

サーバの説明、構成になります。 まずサーバの種類としてラックマウント型とタワー型についての説明があります。 ラックマウント型は拡張が用意でサーバルームなどに常設される時に使用される物で、タワー型は店舗運営のような場所で使用される前提で作られます。 つぎにエントリ・ミドル・ハイエンドサーバについてです。 これらは名前の通り、区分となっており順次値段が高くなり、性能もあがります。 更にIAサーバ、エンタープライズサーバについて簡易的に説明があります。   それら説明の後サーバの選定を行う上でのポイントを挙げていきます。
  • サーバ要件
  • サーバスペックの決め方
    • 実際の環境を試験的に構築し、測定結果から判断する。
    • 仮決めしたサーバスペック機器を本番投入し、実際のハードウェアリソース利用状況を測定した上でサーバやサーバのパーツを増減していく。
    • 消去法でスペックを絞り込んでいく
  • スケールアップとスケールアウト
  • ベンダーを選ぶ
次に書く要件の説明と選ぶポイントとなります
  • CPU
    • パフォーマンスと発熱・消費電力
    • CPU用語
      • ソケット数
      • 動作周波数
      • コア
      • キャッシュ
      • ハイパースレッディング
      • ターボブーストテクノロジー
    • CPU選定のポイント
      • パフォーマンス
      • 価格対比
      • 使うソフトウェアのライセンス体系
  • メモリ
    • パフォーマンス
    • メモリ用語
      • スロット数
      • ECC(Error Correcting Code)memory
      • チャネル
      • ランク
      • UDIMM
      • RDIMM
      • LRDIMM
      • LV(低電力)
    • メモリ表記の見方
    • メモリの挿し方
    • メモリ選定のポイント
      • 搭載容量
      • パフォーマンス
      • 拡張性
  • ディスクの種類
    • SATAハードディスク
    • SASハードディスク
    • FC(Fibre Channel)ハードディスク
    • その他
      • 二アラインハードディスク
      • SSD(Solid State Drive)
      • エンタープライズフラッシュメモリストレージ
  • RAID
    • RAIDレベル
    • RAIDのパフォーマンス
    • RAID5 vs RAID10
    • RAID5 vs RAID6
  • 仮想化
    • 物理サーバと仮想サーバの特性
      • 物理サーバは使用容量が大きい用途に向いています
      • 仮想サーバは使用容量が小さい用途に向いています
    • 物理サーバを仮想化する場合のメリットとデメリット
      • メリット
        • コストダウンが可能
        • ゲストOSのハードウェアリソース増減を容易に行える
        • 他の新しい物理サーバに仮想化環境を用意し簡単に移行できる
      • デメリット
        • 他のゲストOSが大量のハードウェアリソースを使うと、他のゲストOSの動作が不安定になる。
        • 一度作られたゲストOSがその後に使われなくなっても撤去されずに残りがちになる。
    • 仮想化モデル
    • 仮想化環境の種類
      • VMware vSphere
      • Hyper-V(Windows Server 2012)
      • Xen
      • KVM
    • 仮想化環境の選び方
  • クラウド(IaaS)
    • IaaSの特徴
      • 自社で物理サーバを持たずに使えるため、物理サーバを管理するエンジニアが不要
      • 利用申請後、短期間でOSがインストールされた状態ですぐ使える
      • 自社で物理サーバを持たないため、物理的制約を意識せず利用したい分だけサーバ増強が可能
      • 使った分だけ費用が発生する従量課金制
      • 自社で資産を持たずに済むので、サーバを買うと発生する減価償却処理が不要で、かつクラウド利用費はそのまま費用処理が行える
    • クラウド環境でのインフラの利用
    • Amazon Web Services(AWS)
      • Amazon Elastic Compute Cloud(Amazon EC2)
      • Amazon Simple Storage Service(Amazon S3)
    • クラウドに向かない用途
      • 機密情報を置く
      • 大容量ファイルの転送
      • 大規模システム
    • クラウドベンダーの選び方
    • 会計処理から考えるクラウド
これら要点を選定するポイントとして挙げられています。具体的な型番が多く載せられており、より選定者の視点に立って書かれています。  

第三章 OS

第三章では利用されるOSについて説明されています。 まず第一にLinuxです Linuxのディストリビューションとその価格について説明されております。具体的にRedHat Enterprise Linuxの価格とOracle Linuxの価格が挙げられています。   次にWindows Serverです。 Windows Server選定理由としていくつか挙げられています
  • Windows Server上で稼働するソフトウェアを使いたい
  • .NET(ドットネット)基盤を使いたい
  • Active Directory環境を使いたい
さらにWindows Serverのライセンス体系について説明されています。   次にUNIXです。 代表的なUNIX OSとして
  • AIX
  • Solaris
  • HP-UX
が挙げられています。  

第四章 ネットワーク

ネットワーク機器について学び、選ぶ基準を説明していきます。こちらもポイントポイントを押さえていきます。 まずルータの役割が説明されています。ルータは一言で言うとネットワークを論理的に分ける機器となります。 そしてルータを選ぶポイントを5つ挙げています
  • ISPやデータセンターなど、ルータを接続する先から提供される上位回線のインタフェースと一致したWAN側インタフェースを持つこと
  • WAN側での通信帯域
  • スループット
  • セキュリティ機能をルータに求めるか
  • 導入コスト
となります。 次にL2/L3スイッチの役割について説明があり、選ぶポイントが4つ挙げられます。
  • インタフェースの速度とポート数
  • インテリジェントorノンインテリジェント
  • スイッチング能力とスイッチング容量
  • ハードウェア処理 vs ソフトウェア処理
となります。 更にL4/L7スイッチ(ロードバランサー)を選ぶということでロードバランサー(負荷分散機能)付きのL3スイッチのことで、選択肢の一つとして挙げられています。   次はネットワーク設計において良く採用されるパターンをいくつか紹介されています。
  • フロントエンド/バックエンド 2階層構造
  • コア/ディストリビューション/アクセス 3階層構造
  • ネットワークファブリック構造
の三つが挙げられています。   ここからネットワーク用語の解説があります。
  • TCP/IP(Transmission Control Protocol/Internet Protocol)
  • OSI参照モデル
  • TCPとUDP(User Datagram Protocol)
  • 3ウェイハンドシェイク/SYNとACK
  • スイッチングとルーティング
  • IPv4とIPv6
  • ネットワークインタフェースを束ねる
    • ボンディング
    • チーミング
    • リンクアグリゲーション
    • イーサチャンネル
    • ポートトランキング
これらの解説後、インターネットとの接続、ネットワークケーブルについて説明されています。 接続する料金体系はおおよそ二種類で
  • 固定帯域使い放題
  • 従量課金
となります。ネットワークケーブルは
  • LANケーブル
  • 光ファイバーケーブル
の二種類について説明されています  

第五章 ストレージ

ストレージにはサーバ内部のローカルストレージとサーバ外の外部ストレージがあり、外部ストレージにはサーバに直接接続するもの(DAS:Direct Attached Storage)とネットワーク経由で接続するもの(NAS:Network Attached Storage・SAN:Storage Area Network)があります。更にFC-SAN(Fibre Channel SAN),IP-SAN(Internet Protocol SAN)という種類があります。 次にRAIDとホットスペアについてです。ホットスペアとは他のディスクが壊れたときの為に待機しているスタンバイディスクのことです。その動きも解説されています。 次は外部ストレージの利用と題して導入する動機が4つ挙げられます。
  • 記憶領域を大きく取りたい
  • ディスクI/O性能の向上
  • ストレージの統合・集中管理
  • 複数サーバ間でのデータ共有
となります。 また、ストレージの高度な機能として
  • シンプロビジョニング(Thin Provisioning)
  • 自動階層化
  • デデュープ(De-duplication)
  • スナップショット
の説明と使いどころが挙げられています。    

第六章 購買と商談

この章では名前の通り、インフラ整備する上での購買と商談についてのポイントが書かれています。 まず、購買先の選定をし、来訪してもらう目的を考えておき、ベンダーを選定、そして相見積もりを出し、導入テストをするという流れを説明しています。そして、グローバル購買の検討もするように書かれています。 次に資産管理として大事なポイントが挙げられます。
  • 資産管理対象
  • 資産管理の方法
  • 在庫
  • 減価償却
  • 棚卸し
  • 機器の廃棄
について書かれています。  

第七章 データセンター

ネット上や書籍で情報の少ないデータセンターの選定方法などを紹介されています。 まずデータセンターの空調設備の種類をみていきます
  • 床下冷気方式
  • 排熱吸引方式
  • 外気空調方式
があります。そこを見つつ、データセンターの選定をしていきます。 データセンターを選ぶポイント
  • データセンターの立地
  • サーバ設置台数
  • ラックは持ち込みか、貸し出しか
  • 利用可能ボルト数
  • 重荷重機器への対応
  • 防災レベルUPS(無停電装置)や発電機の性能
  • 産廃処理
  • 搬入スペースや駐車場の有無
  • リモートハンドサービスの有無
  • ユーザルームの有無
  • ケージ(金網)の有無
  • ネットワーク回線のコネクティビティー
  • イレギュラーな要望に強い
  • 備品貸し出し柔軟性
  • 売店や宿泊施設の有無
  • 費用
が挙げられています。実際に使用してきた経験で書かれていて参考になります。   そしてデータセンターで行われることとしてラックに機器を取り付ける方法が載せられています。 次に自社サーバールームを使う為のポイントを挙げられています
  • 面積
  • 電力容量
  • 冷却
  • 耐荷重
  • 地震対策
  • 騒音対策
  • ホコリ対策
  • 法定点検対策
  • セキュリティ
  • 備品置き場
これらを考えてサーバルームを作ることが必要だと書かれています。  

第八章 ソリューションとセキュリティ

次に管理の方法としてソリューションの種類を挙げていきます。
  • 監視ソリューション
    • Nagios(ナギオス)
    • Zabbix(ザビックス)
    • Cacti(カクタイ)
  • 資産管理ツール
  • 配信システム
  • セキュリティ
  • ファシリティ管理システム
  • ストレージ管理システム
つぎにセキュリティ対策について書かれています。 セキュリティにはセキュリティ担当者とサーバ担当者の連携をしっかり行うこと、外部セキュリティ企業の活用、データのハッシュ化と暗号化が必要であると書かれています。  

第九章 インフラ運用

インフラ運用についてまず、障害対応についてかかれています。 ハードウェアは必ずいつか壊れるという考えのもとで障害対応を行っていくことが大事であるとあります。 次にボトルネックを解消するということで、システムのレスポンスを向上することはもちろん、計画的に行い、対策を行わなければハードウェアリソースが枯渇するような状況になってしまうため、重要だと書かれています。さらにネットワーク機器のボトルネックの解消、サーバ機器のボトルネックの解消について調べ方と対策が書かれています。 次に MSP(Managed Service Provider)業者の選び方として
  • 企業としての信頼性
  • コミュニケーション力
  • 柔軟性
  • 技術力
  • 費用対効果
が挙げられ、その具体的なコストが書かれています。 次にファームウェアについてです。 ファームウェアについて注意すべきこととして
  • ファームウェアのバージョンとレベル
  • ファームウェアのバージョンアップの要否を判断する
  • 最新ファームウェアの情報を収集する
  最後にハードウェアの保守として、あるといいサービスなどが書かれています。  

第十章 大規模インフラ

この章では大規模インフラの管理として必要なポイントを挙げていきます。 システム構成を決めるポイントとして
  • ベンダーサポートの必要性
  • 使用言語
  • アクセス量
  • 可用性
が挙げられ、さらに外部業者を活用する場面として
  • 納品機器の開梱とラックへのマウント
  • 配線
  • 機器のセットアップ
  • 障害対応サポート
  • サーバルームの清掃
  • インフラ運営システムの開発
  • ハードウェア故障時の自動対応
が挙げられます。 次にCDN(Contents Delivery Network)についてです。静的コンテンツの配信に使われます。 また、CDNを使うことで外部からの不正アクセスや攻撃を軽減する効果も期待されます。 CDNを提供している代表的な業者も挙げられています。 業者の選び方のポイントは
  • 品質
  • サービスは国内限定かそれとも世界を対象か
  • コスト
が挙げられています。   次にDSR(Direct Server Return)構成を用いた負荷分散について書かれています。 前述したロードバランサーで用いられる負荷分散手法の一つで、大規模WEBサイトなどで用いられます。 一般的な構成とDSR構成の違いを図で説明されており、DSR構成のメリットが三つ挙げられています
  1. リクエスト量に対するL4スイッチのキャパシティが増える
  2. ネットワーク構成が比較的自由になる
  3. 使用するポート数は1ポートのみ
となります。 そのなかで、DSR構成が一般的でない理由として、全てのサーバに対してループバックと呼ばれる仮想ネットワークインタフェース設定を行っていく必要があるので、設定項目が増えることに加えて、不慣れな人が多いということが挙げれています。   最後にリソース不足対策についてかかれます。 まずリソース不足の種類です
  • 人的リソース不足
  • データセンタースペース不足
  • 機器不足
  • ネットワーク帯域不足
  • 資金不足
があげられます。そして、LINEサービスを例に大規模インフラの具体案を説明されています。    

第十一章 インフラエンジニアの成長

最後の章ではインフラエンジニアはどうしていくべきかということが書かれています。 まずインフラエンジニアが身につけるべきこととして
  • ドキュメントを読み込み力を付ける
  • カタログを読み込む力を付ける
の二つが挙げられています。 さらに小規模インフラと大規模インフラで身につく経験の違いなどが挙げられます。 最後にインフラエンジニアの育成についてタイプ別に書かれており、好奇心が強い方、好奇心が弱い方の2つのタイプ別にどのような育成をおこなうとよいかが書かれています。   以上まとめとなります。 項目ごとに最低限の情報を分かりやすくかいてあるので、ハンドブックとしても活用できそうな本でした。

備忘録 〜インフラ〜

こんにちは、うさです。 今回は「インフラ」について、 こちらの参考書をまとめていきます。

第1章 インフラエンジニアの仕事

インフラエンジニアの仕事は「インフラ設計」、「インフラ構築」、「インフラ運用」の3つのフェーズに分けられる 「インフラ設計」
  1. インフラを作る目的を理解する
  2. 目的を達成する為に必要な機能・性能などを要件としてまとめる
  3. 要件に合う企画書や設計書を作成する →どのくらいの費用で、どのくらいの期間で作れるかを算定
「インフラ構築」 インフラ構築作業は、機器の運搬・機器の組み立て・機器の取り付け・機器のインストールや設定・動作テスト・負荷テストに分けられる 「インフラ運用」 インフラ運用は下記のように区分できる
  • 障害対応:ハードウェアの故障の対応や急激なアクセス増への対策、不適切な権限設定によるアクセス出来ない状況の解消などがある
  • キャパシティ管理:構築したインフラの規模をアクセス数やデータ量に応じて適正化する
  • インフラ起因でない原因の切り分け:システムに障害が発生した場合、インフラ起因であるかプログラムおける問題かを切り分けて対応する

第2章 サーバ

サーバの選定

サーバスペックの決め方は3つの考え方がある
  • 実際の環境を試験的に構築し、測定結果から判断 →基幹系システムの中核の担うシステムや重要なシステムの場合
  • 仮決めしたサーバスペック機器を本番投入し、実際のハードウェアリソース利用状況を測定した上でサーバやサーバのパーツを増減していく →実際にリリースしてみないとアクセス量が判断できない場合
  • 消去法でスペックを絞り込んでいく →ある程度サービスの性質が特定されている場合
サーバスペックを決めた後は、ベンダーを選ぶ。 価格やサービスを総合的に判断する。 サーバのキャパシティを向上させるアプローチとして
  • スケールアウト:性能が足りなくなったらサーバの台数を増やす
  • スケールアップ:性能が足りなくなったらメモリの増設などでサーバの性能を増やす
の2つの方法がある。

CPU

CPU選定のポイント
  • パフォーマンス:求める演算能力を満たすか
  • 価格対比:求める処理能力、将来の拡張性から価格的に妥当か
  • 使うソフトウェアのライセンス体系:CPUのコア数やソケット数によって価格が変わるソフトウェアがある為、総コストを減らす為にCPUの種類や個数を調整
  • 消費電力:省電力CPUは動作周波数を落とすことで省電力を実現したCPU。単価は普通のCPUより上がるが、運用年数で計算する

メモリ

メモリの選定のポイント
  • 搭載容量
  • パフォーマンス:メモリコントローラが扱えるランク数制限ぎりぎりまで使い切り、マルチプロセッサ環境下でマルチチャンネルを実現するとパフォーマンスが向上
  • 拡張性:メモリスロットの数が限られるので、拡張が発生する場合は高価でも大容量メモリを選ぶ

RAID

RAIDのレベルは「0」〜「6」までの7種類が存在し、 RAID0と他のRAIDレベルを組み合わせたものも存在する。 よく使われるRAIDレベルと用途を見ていく
  • 「0」:耐故障性のないディスクアレイ(ストライピング) →ディスクI/O性能を上げたい場合に使う。耐障害性が弱い。ログ集計などの一時記憶領域などで使われる。
  • 「1」:二重化(ミラーリング) →耐障害性が強い。OSが入っているパーティションなどで使われる。
  • 「5」:ブロック単位でパリティ情報記録 →保存容量を多めに確保したい場合に使われる。ファイルサーバやログ保存等で使われる。
  • 「6」:ブロック単位で2種類のパリティ情報記録 →RAID5と用途は同じだが、耐障害性が強い。
  • 「10」:RAID1をストライピングしたもの →耐障害性とディスクI/O性能を満たす。データベースなどで使われる。
  • 「50」:RAID5をストライピングしたもの →保存容量確保とディスクI/O性能を満たす。ファイルサーバやログ保存などで使われる。
  • 「60」:RAID6をストライピングしたもの →RAID50と同様

仮想化

仮想サーバ・・・1台の物理サーバ上に複数のゲストOSを稼働させること 物理サーバと仮想サーバの特性
  • 物理サーバ:CPU使用率、ディスクI/O負荷・ディスク使用容量が大きい用途に向く。 →用途:データベースサーバ、アプリケーションサーバ
  • 仮想サーバ:CPU使用率、ディスクI/O負荷・ディスク使用容量が小さい用途に向く。 →用途:Webサーバ、開発サーバ、メモリDB
仮想化のメリット
  • コストダウン
  • ゲストOSのハードウェアリソース増減を容易に行える
  • 物理サーバが老朽化した際、ハードウェア交換が必要なのに対し、 ゲストOSは新しい物理サーバに仮想化環境を用意し、簡単に移行が出来る
仮想化のデメリット
  • 他のゲストOSが大量のハードウェアリソースを使うと、他のゲストOSの動作が不安定になる
  • 一度作られたゲストOSがその後使われなくなっても撤去されずに残りがちとなる

クラウド(IaaS)

クラウドは以下の3種類に分類される
  • SaaS:アプリケーションをサービスとして提供
  • PaaS:アプリケーション実行環境をサービスとして提供
  • IaaS:システムインフラをサービスとして提供
IaaSの特徴
  • 自社で物理サーバを持たずに使えるため、物理サーバを管理するエンジニアが不要
  • 利用申請後、短期間でOSがインストールされた状態ですぐ使える
  • 自社で物理サーバを持たないため、物理的成約を意識せず利用したい分だけサーバの増強が可能
  • 使った分だけ費用が発生する従量課金制
  • 自社で資産を持たずにすむので、サーバを買う発生する減価償処理が不要で、クラウド利用費は費用処理が行える
クラウドに向かない用途
  • 秘密情報を置く:自社で管理できないところで機密情報流出が発生するリスクがある。
  • 大容量ファイルの転送:ファイル転送が遅くなる
  • 大規模システム:自社で機器を持った方が安くなる

第3章 OS

Linux、Windows Server、UNIXについて代表的OSの記述

第4章 ネットワーク

ルータ ルータを選ぶポイント
  1. ISPやデータセンターなど、ルータを接続する先から提供される上位回線のインタフェースと一致したWAN側インタフェースを持つこと
  2. WAN側での通信帯域
  3. スループット:単位時間当たりのデータ転送量
  4. セキュリティ機能をルータにも求めるか:フィルタリング機能などを持たせるか
  5. 導入コスト
スイッチ L2/L3スイッチの役割
  • L2スイッチ:スイッチングハブ。 フレーム(L2スイッチではパケットではなくフレームと呼ぶ)が入ってくると、 宛先のMACアドレスを見て適切なポート番号にフレームを転送。 該当するMACアドレスが存在しない場合はLAN全体にブロードキャストを飛ばし、応答があったポートに転送。
  • L3スイッチ:ルータ機能付きのL2スイッチ。 パケットがが入ってくると、宛先のIPアドレスを見て適切なポートにパケットを転送。 該当するIPアドレスもしくはネットワークアドレスが存在しない場合は、デフォルトゲートに繋がるポートに転送。
L2/L3スイッチを選ぶポイント
  • インターフェースの速度とポート数
  • インテリジェントorノンインテリジェント
    • インテリジェント:スイッチにWeb接続もしくはtelnet接続することで各ポートの設定を変更することや、各ポートのステータスや通信量を確認することが出来る
    • ノンインテリジェント:サーバがネットワークに繋げるようにするだけであれがノンインテリジェントで十分である
  • スイッチング能力とスイッチング容量
    • スイッチング能力:一秒間のうちにどの程度のパケットを処理できるか
    • スイッチング容量:一秒間のうちにどの程度のバイト数を処理できるか
  • ハードウェア処理vsソフトウェア処理 通信量が大規模の場合ソフトウェア処理によってCPU使用率が上がってスイッチング能力に影響を与える場合がある

ネットワークケーブル

LANケーブル:LANケーブルは多くの種類が出ているが、通信品質に大きな差はない。 光ファイバーケーブル:
  • マルチモードファイバ:伝送距離が短いが安価
  • シングルモードファイバ:伝送距離が長いが高価

第5章 ストレージ

データを記憶する装置のことをストレージ
  • ローカルストレージ:サーバ内にディスクを搭載して用いる記憶領域 設置場所はコンパクトですが、搭載できるディスクの本数や拡張性は少ない
  • 外部ストレージ:サーバ外に用意するストレージ機器もじくはストレージ領域
    1. DAS:サーバに直結するストレージ機器。 DASを選ぶ際は、必要な実容量、パフォーマンス、耐障害性、拡張性を考える。
    2. NAS:ネットワーク経由で複数のサーバからアクセス可能なストレージ。 複数のサーバ間でデータ共有や複数のサーバでバックアップやログファイルを一カ所にまとめる用途で使われる。
    3. SAN:ブロックレベルのデータストレージ専用のネットワーク。 高速・高品質な環境を求める時に用いる。
外部ストレージを導入する動機としては、以下の4つが挙げられる
  • 記憶領域を大きく取りたい
  • ディスクI/O性能の向上
  • ストレージの統合・集中管理
  • 複数サーバ間でのデータ共有

第6章 購買と商談

インフラ構築の為の機器等の購入は、ベストは信頼のおける知り合いから良いベンダーを紹介してもらうこと。 ベンダーに来訪してもらう際、以下のことを把握しておくべき
  • 何を購買しなければならないのか
  • 購買しようとしているものの価値の相場の把握
  • 購買しようとしているもののトップシェアベンダー
  • 発注から納品までどれくらいの期間がかかるのか
初めて機器を導入する場合、導入テストを行う場合がある。 設置場所に収まるかといった物理的な確認、 必要な性能は出るかといったパフォーマンス測定、 サーバ等の接続確認。

第7章 データセンター

データセンターの選定 アプローチ方法としては、
  • 知り合いからの紹介
  • サーバベンダー等、付き合いのあるベンダーからの紹介
  • ホームページなどでモボ私意データセンターを探す
データセンターを選ぶポイント
  1. データセンターの立地
  2. サーバ設置台数:サーバ設置空間は後で増やすことが困難なため拡張性も考慮に入れる
  3. ラックは持ち込みか、貸し出しか:ラックとラックマウントには相性があり、取り付けられない場合がある
  4. 利用可能ボルト数:大型機器は200V電源が必須な場合がある
  5. 重荷重機器への対応:サーバルームの耐荷重の確認
  6. 防災レベル:災害に対しての備えがあるか
  7. UPS(無停電装置)や発電機の性能
  8. 廃棄処理:データセンターでやってくれるかどうか
  9. 搬入スペースや駐車場の有無
  10. リモートハンドサービスの有無:トラブル発生時、電話をかければ電源をオン/オフにしてくれるサービスがあるかどうか
  11. ユーザルームの有無:オペレータがデータセンターに常駐する為のユーザルームが借りれるかどうか
  12. ケージ(金網)の有無
  13. ネットワーク回線のコネクティビティー:自前でISPと専用回線契約できるかどうか
  14. イレギュラーな要望に強い
  15. 備品貸し出しの柔軟性
  16. 売店や宿泊施設の有無
  17. 費用:最終的には費用で決めることとなる

第8章 ソリューションとセキュリティ

ソリューション

監視ソリューション:機器の稼働状況を一括監視する為に監視ソリューションを利用する。 区分すると、SNMPを利用するものと各サーバにエージェントプログラムをインストールしてそのデータを収集するものがある。

セキュリティ

インフラにおいての守るべきものとは、
  • 顧客データ全般
  • 売上情報
  • メールデータ
  • 各種ドキュメント類
  • 各種ソースコード
  • 従業員名簿

第9章 インフラ運用

ボトルネックを解消する ITシステムでは一般的にボトルネックが一カ所あるだけでスステム全体のレスポンスに悪影響を与える。 ボトルネックのおこりやすい場所は
  • コアスイッチのキャパシティ
  • L2スイッチのキャパシティ
  • Webサーバのメモリ不足
  • データベースサーバのCPUやメモリ不足
  • データベースサーバのディスクI/O
MSP MSPとはITインフラの運用管理を代行してくれる業者 MSP業者を選ぶポイントは
  • 企業としての信頼性:コンプライアンス面、財務状況等も確認すべき
  • コミュニケーション力
  • 柔軟性
  • 技術力
  • 費用対効果

第10章 大規模インフラ

システム構成を決めるポイント
  • ベンダーサポートの必要性
  • 使用言語
  • アクセス量
  • 可用性
外部業者の利用が必要になってくる
  • 納品機器の開梱とラックへのマウント
  • 機器のセットアップ
  • 障害対策サポート
  • サーバルームの清掃
  • インフラ運営システムの開発
  • ハードウェア故障時の自動対応
CDN 画像や実行ファイルなどの静的コンテンツの配信にCDNを使う CDNは、サービス提供会社のサーバに変わってCDNベンダーが提供したキャッシュサーバにアクセスしてユーザが静的コンテンツを取得する CDN業者ぼ選び方
  • 品質:サービスダウンがないか、応答速度が十分であるか
  • サービスは国内限定か、それとも世界対象か
  • コスト:CDNを使う場合に想定される通信量とCDNを使わない場合のインフラ投資・運用費用の比較
リソース不足対策
  • 人的リソース不足
    • コアメンバー:インフラ全体を管理する
    • オペレーター:実作業を遂行する
    コアメンバーは大規模インフラの経験者が少ない上、転職市場に出回らない。 →新卒を数年かけて育成する方が早いかもしれない オペレーターは転職市場に多く存在する。 実務経験がなくても比較的短期間で育成が可能。
  • データセンタースペース不足 成長著しいWebサイトの場合ものすごい勢いでラックスペースを使っていく。 また複数のデータセンターにサーバを分離出来ない場合もあるため、全部のサーバを別のデータセンターに移転させなければならないこともある。
  • 機器不足 大規模サイトの場合、大量発注となる場合が多いため、ベンダー側との生産調整が必要になる
  • ネットワーク帯域不足 アップリンクが1Gbpsを超えるとコアルータのアップリンクも1Gbps増やさなければならない。 ルータがキャパシティの限界となった場合はデータセンターの移転も必要
  • 資金不足 成長基調にあるITベンチャー企業は成長期において資金不足に陥り、思うように必要インフラ投資をおこないことがある。 その場合には →中古品を活用する チューニングを行う →日頃付き合いのある企業に助けを求める →増資を求める

第11章 インフラエンジニアの成長

  • ドキュメントを読み込む力を付ける
  • カタログを読み込む力を付ける
小規模インフラと大規模インフラ 経験や身につけられることが違う
  • 小規模インフラ ITインフラ全般を少人数で扱う。 企画、設計、商談、構築、運用の経験ができることが最大のメリット。 予算が限られた中での最大の費用対効果を実現する為にチューニング等を行っていく。
  • 大規模インフラ ITインフラを大人数で分担して構築、管理していく。 特定の分野に対して、高度なスキルが必要となる。 予算は多くかけられる分、可用性が求められる。
まとめ インフラ構築において、こういった場合にはこれを選ぶといいといった具合に、 一つ一つのケース毎にわかりやすく解説がなされており、 自分がインフラ構築する際にはしっかりとデータを収集した上で、行く通りの選択肢から最適なものを選ぶようにしていきたい。 以上、インフラについての備忘録を終了する。

備忘録 〜セキュリティ〜

こんばんは、うさです。 本日は、セキュリティについての書籍を読んでまとめていきます。 今回参考にさせて頂いた書籍はこちら。

第1章 Webアプリケーションの脆弱性とは

アプリケーションのバグにおいて悪用ができてしまうものを脆弱性(セキュリティバグ)と呼ぶ。 →この脆弱性があってはいけない理由
  1. 経済的損失
    • 利用者が受けた金銭的損失の補填、補償
    • 迷惑料として配る金券等の費用、配送料
    • Webサイト停止による機会損失
    • 信用失墜による売上の減少
  2. 法的な要求: Webサイトの安全対策を要求している法律として、「個人情報の保護に関する法律」があり、 5000件を越える個人情報を保持する事業者は個人情報取扱事業者として安全管理措置を講じる義務がある
  3. 利用者が回復不可能なダメージを受ける場合がある: 利用者の個人情報が漏洩した場合、元の状態に戻すことは不可能である。金銭的に解決は出来ても精神面の解決はできない。
  4. Webサイト利用者に嘘をつくことになる: 多くのWebサイトは安全性をうたっている。ここで脆弱性があると安全性に大きく影響をする。
  5. ポットネットワーク構築に荷担する: サイトを閲覧した利用者のPCがボットに感染し、それにより攻撃者の指令を受けて操作されてしまう可能性がある。 ボットネットワークに組み込まれたPCは迷惑メール送信やDDoS攻撃に荷担する。 また、ボットからサーバーに対して攻撃されることもある。
では、脆弱性が生まれる理由とは・・・
  1. バグによるもの→ セキュリティに無関係なところで発生し、アプリケーション全体に影響が及ぶ (例)SQLインジェクション、クロスサイト・スクリプティング等
  2. チェック機能の不足によるもの→ セキュリティ上のチェックが甘いことにより発生し、アプリケーション全体に影響が及ぶ (例)ディレクトリ・トラバーサル脆弱性等

第2章 自習環境のセットアップ

この章では仮想的にLinuxサーバーが動作する環境を作り、Webサーバーに見立てての実習のための環境設定を行っているので、割愛する。

第3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー〜

3-1 HPPTとセッション管理

HTTPを学ぶ理由:Webアプリケーションの脆弱性には、Web固有の特性に由来するものがあるため ブラウザは、サーバーへ要求としてHTTPリクエスト(リクエストメッセージ)を送信し、サーバーはブラウザへの返信としてHTTPレスポンス(レスポンスメッセージ)を返す。 リクエストメッセージには「Referer」というヘッダが付く場合がある。 これが役立つ場合は、セキュリティ確保を目的として積極的にチェックする場合であり、 反対に問題になる場合は、URLが秘密情報を含んでいる場合。 <GETとPOSTの使い分け> リクエストメッセージの1行目はリクエストラインと呼ばれ、「GET」と「POST」が存在する。 使い分け方としては、
  • GETメソッドは参照(リソースの取得)のみ用いる
  • GETメソッドは副作用がないことが期待される
  • 秘密情報の送信にはPOSTメソッドを用いること
また、POSTで送信すべき理由としては、
  • URL上に指定されたパラメータがReferer経由で外部に漏洩する
  • URL上に指定されたパラメータがアクセスログに残る
上記をまとめると以下の中で1つでも当てはまる時はPOSTで、1つも当てはまらない時はGETを利用すべき
  • データ更新など副作用を伴うリクエストの場合
  • 秘密情報を送信する場合
  • 送信するデータの送料が多い場合
<hiddenパラメータ> 利用者の入力した値はhiddenパラメータとしてHTMLソース上に記述される そして、このhiddenパラメータは書き換え可能である。 メリットとしては、書き換え可能であると記述したが、情報漏洩や第三者からの書き換えに対しては堅牢である。 <クッキーとセッション管理>
  • セッション管理:アプリケーションにおいてログインした状態をサーバー側で覚えておくこと
  • クッキー:サーバー側からブラウザに対して「名前=変数」の組を覚えておくように指示するもの
クッキーはアプリケーションデータを保持する目的でクッキーに値を入れることはあまり行われない。 その理由は、
  • クッキーが保持できる値の個数や文字列長には制限がある
  • クッキーの値は利用者本人には参照・変更できるので、秘密保持の格納には向かない

3-2 受動的攻撃と同一生成元ポリシー

Webアプリケーションに対する攻撃は、能動的性攻撃と受動的攻撃に分類される。
  • 能動的攻撃:攻撃者がWebサーバーに対して直接攻撃すること。
  • 受動的攻撃:攻撃者がサーバーを直接攻撃するのではなく、Webサイトの利用者に罠を仕掛けることにより、罠を閲覧したユーザを通してアプリケーションを攻撃する手法。
『正規サイトを悪用する受動的攻撃』 以下の順で攻撃される
  1. 攻撃者が正規サイトを攻撃してコンテンツに仕掛けを仕込む
  2. 仕掛けられた正規サイトを利用者が閲覧する
  3. マルウェア感染などがおこる
この手法の攻撃者のメリットは、
  • 罠サイトに誘導する手間がいらない
  • 正規サイトは利用者が多いので被害が拡大する可能性が高い
  • 正規サイトの機能を不正利用することにより攻撃者にメリットが得られる
  • 利用者の個人情報を盗むことにより攻撃者にメリットが得られる
この手法は以下の4つがよく用いられる
  • FTPなどのパスワードを不正入手してコンテンツを書き換える
  • Webサーバーの脆弱性をついた攻撃によりコンテンツを書き換える
  • SQLインジェクション攻撃によりコンテンツを書き換える
  • SNSなどの利用者が投稿できるサイト機能をクロスサイト・スクリプティング脆弱性を悪用する
『サイトをまたがった受動的攻撃』 以下の順で攻撃される
  1. 利用者が罠サイトを閲覧する
  2. 罠サイトから、仕掛けを含むHTMLをダウンロードする
  3. HTMLの仕掛けが発動して正規サイトに攻撃のリクエストを送信する
  4. 正規サイトからJavaScriptなどの仕掛けを含むレスポンスが返る
では、ブラウザはどのように受動的攻撃を防ぐのか サンドボックス:プログラムができることに制限があり、悪意のあるプログラムを作ろうとしても利用者に被害が及ばないように配慮されている 一般的に、以下の機能が制限される
  • ローカルファイルへのアクセスの禁止
  • プリンタなどの資源の利用禁止
  • ネットワークアクセスの制限(同一生成元ポリシー)
上記に記載した「同一生成元ポリシー」とは、JavaScriptによるサイトをまたがったアクセスを禁止するセキュリティ上の制限である。 同一生成元である条件として、
  • URLのホストが一致している
  • スキーム(プロトコル)が一致している
  • ポート番号が一致している
ブラウザは同一生成元ポリシーにより受動的攻撃を防止しているが、アプリケーションに脆弱性があると受動的攻撃を受ける場合がある。

第4章 Webアプリケーションの機能別に見るセキュリティバグ

4-1 Webアプリケーションの機能と脆弱性の対応

まずは、以下にWebアプリケーションでよく用いられる処理と混入しやすい脆弱性を示す。
  • HTMLへの出力→クロスサイト・スクリプティング
  • HTTPヘッダの出力→HTTPヘッダ・インジェクション
  • SQLの呼び出し(発行)→SQLインジェクション
  • シェルコマンドの呼び出し→OSコマンド・インジェクション
  • メールヘッダ及び本文の出力→メールヘッダ・インジェクション

4-2 入力処理とセキュリティ

Webアプリケーションの入力では何をするのか →HTTPリクエストとして渡されるパラメータの値の受付時の処理(以後、入力処理とする) 入力処理では以下の処理を行う
  • 文字エンコーディングの妥当性検証
  • 文字エンコーディングの変換
  • パラメータ文字列の妥当性検証
文字エンコーディング関連の処理が終わった後、入力値の検証を行う。 入力値検証の目的は
  • 入力値の間違いを早期に発見して再入力を促すことにより、ユーザビリティ(使いやすさ)を向上する
  • 間違った処理を継続することによるデータの不整合などを防ぎ、システムの信頼性を向上させる
入力値検証の主目的はセキュリティのためではないが、以下のようなケースにおいてセキュリティの役に立つ。
  • SQLインジェクション対策が漏れていたパラメータがあるが、英数字のみ許可していたので実害には至らない
  • PHPのバイナリセーフでない関数を使っているが、入力段階で制御文字をチェックしているので実害には至らない
  • 表示処理の関数に文字エンコーディングの指定を怠っているが、入力段階で不正な文字エンコーディングをチェックしているので実害には至らない
上記に出てきたバイナリセーフとは・・入力値がどんなバイト列であっても正しく扱えること →値ゼロのバイト(ヌルバイト)が現れても正しく処理できる このヌルバイトを利用した攻撃もある その為、アプリケーションの入り口でバイナリセーフの関数を用いて入力値のヌルバイトをチェックし、ヌルバイトがあればエラーにすることにより対応が可能 しかし、入力値検証だけでは対策にならない。 なぜなら、「すべての文字を許容する」というアプリケーションの仕様の場合は入力時点では何も防げない。 その対策としては、
  • 制限文字のチェック
  • 文字数のチェック
を行う。

4-3 表示処理に伴う問題

表示処理が原因で発生するセキュリティ上の問題は以下がある。
  • クロスサイト・スクリプティング
  • エラーメッセージからの情報漏洩
<クロスサイト・スクリプティング> 『概要』 Webアプリケーションには外部からの入力などに応じて表示が変化する箇所があり、この部分のHTML生成の実装に問題があるとクロスサイト・スクリプティング(以下、XSSと省略する)が生じる その場合の影響としては以下が挙げられる。
  • サイト利用者のブラウザ上で、攻撃者の用意したスクリプトの実行によりクッキー値を盗まれ、利用者に成りすましの被害にあう
  • 同じくブラウザ上でスクリプトを実行させられ、サイト利用者の権限でWebアプリケーションの機能を悪用される
  • Webサイト上に偽の入力フォームが表示され、フィッシングにより利用者が個人情報を盗まれる
『攻撃手法』
  • クッキーの盗み出し
  • JavaScriptによる攻撃
  • 画面の書き換え
それぞれの攻撃について。 まずは、「クッキーの盗み出し」
  1. 攻撃者は脆弱なサイトの正規利用者を罠サイトに誘導する
  2. 正規利用者が罠サイトを閲覧すると、XSS攻撃により、クッキー値をクエリー文字列につけて、情報収集ページに遷移する。
  3. 情報収集ページは受け取ったクッキー値をメールで攻撃者に送信する。
続いては、「JavaScriptによる攻撃」 現在は、Ajaxの流行により、アプリケーションの様々な機能を呼び出すためのAPIが用意されているWebサイトが増加している。 APIは攻撃に悪用することも可能なので、XSSとJavaScriptの組み合わせによる攻撃がしやすくなっている。 最後に、「画面の書き換え」 攻撃者はリンクに見せかけたボタンを用意し、それをクリックすると、 もとのformを隠し、新たなformを追加することにより改変された画面へと誘導される。 そこに個人情報などを入力させて盗む。 『脆弱性の生まれる原因』 HTML生成の際に、HTMLの文法上特別な意味を持つ特殊記号を正しく使っていないことであり、それにより、HTMLやJavaSriptを注入・変形される現象がXSSである。 『基本的対策』
  • 要素内容については「<」と「&」をエスケープする
  • 属性値については、ダブルクォートで囲って、「<」と「”」と「&」をエスケープする
『保険的対策』
  • 入力値検証を行い、条件に一致しない入力の場合にはエラーを表示して再入力を促す
  • クッキーにHttpOnly属性を付与して、JavaScriptからのクッキーの読み出しを禁止する
  • TRACEメソッドの無効化にすることで、クロスサイト・トレーシングというJavaScriptによりHTTPのTRACEメソッドを送信することにより、クッキー値やBasic認証のパスワードを盗み出す攻撃に対処できる
<エラーメッセージからの情報漏洩> エラーメッセージからの情報漏洩については以下の2種類がある。
  • エラーメッセージに攻撃者にとって有益なアプリケーションの内部情報が含まれる
  • 意図的な攻撃として、エラーメッセージに秘密情報を表示させられる

4-4 SQL呼び出しに伴う脆弱性

<SQLインジェクション> 『概要』 SQLインジェクションはSQLの呼び出し方に不備がある場合に発生する脆弱性。 以下の影響を受ける場合がある。
  • データベース内のすべての情報が外部から盗まれる
  • データベースの内容が書き換えられる
  • 認証を回避される(ID、パスワードを用いずにログイン)
  • その他、データベースサーバ上のファイルを読み出し、書き込み、プログラムの実行などが行われる
『攻撃手法と影響』
  • エラーメッセージ経由の情報漏洩:あるURLを表示するとエラーメッセージが表示され、そこにユーザIDやパスワードが表示され、情報漏洩となる
  • UNION SELECTを用いた情報漏洩:UNION SELECTは2つのSQL文の結果の和集合を求める演算で、これにより、意図しない情報が表示されてしまう
  • SQLインジェクションによる認証回避:SQLインジェクション脆弱性があると、パスワードを知らなくてもログインできてしまう場合がある
  • SQLインジェクション攻撃によるデータ改ざん::iframe要素やscript要素を埋め込み、Webサイトの利用者のPCにマルウェアを感染させるように誘導する攻撃
『脆弱性が生まれる原因』
  • 文字列リテラルの問題:SQLの標準規格では、文字列リテラルはシングルクォートで囲む。 しかし、シングルクォートを重ねることを忘れてしまうと脆弱性が生まれる
  • 数字項目に対するSQLmインジェクション:数字リテラルはシングルクォートで囲まれないため、数値でない文字が現れた時点で数値リテラルは終了する。その後の文がSQL文として解釈されてしまう。
『対策』
  1. プレースホルダによりSQL文を組み立てる
  2. アプリケーション側でSQL文を組み立てる際に、リテラルを正しく構成するなど、SQL文が変更されないようにする
上記2つのうち2は対策が難しいため、1による対策が良い <プレースホルダによるSQL文組み立て> SQL文中のクエッションマークがプレースホルダであり、変数や式などの可変パラメータの場所に埋め込んでおくもの。 プレースホルダには「静的プレースホルダ」と「動的プレースホルダ」がある。
  • 静的プレースホルダ:値のバインドをデータベースエンジン側で行う。
    1. プレースホルダのついたSQL文はデータベースエンジンに送られ、コンパイルなどの実行準備が行われ、SQL文が確定
    2. バインド値がデータベースエンジンに送られ、エンジン側で値を当てはめたSQL文が実行
    →プレースホルダの状態でSQL文がコンパイルされるため、後からSQL文が変更される可能性は原理的にあり得ない。
  • 動的プレースホルダ:SQLを呼び出すアプリケーション側のライブラリ内で、パラメータ内をバインドしてからデータベースエンジンに送る方式。 バインドに当たりリテラルは適切に構成されるため、処理系にバグがなければSQLインジェクションは発生しない。
『保険的対策』
  • 詳細なエラーメッセージの抑止:先ほど記載した通り、エラーメッセージにより情報を得られてしまうため、詳細なエラーメッセージを抑止することで被害に遭いにくくする
  • 入力値の妥当性検証:4-2節のようにアプリケーション要件に従った入力値検証を行うと、脆弱性対策になる可能性がある
  • データベースの権限設定:アプリケーションを利用するデータベースユーザに対しては、アプリケーションを実現するために必要最低限な権限のみ与えることで被害を最小限に抑えられる

4-5 「重要な処理」の際に混入する脆弱性

「重要な処理」→ログインした利用者のアカウントにより、取り消しできない重要な処理が実行できるもの <クロスサイト・リクエストフォージェリ> 『概要』 「重要な処理」の受付に際し、利用者を意図したリクエストであることを確認する必要がある。 しかし、この確認処理が抜けていると、罠サイトを閲覧しただけで、利用者のブラウザから勝手に「重要な処理」を実行させられてしまう。 以下、クロスサイト・リクエストフォージェリ(以下CSRFと略す)の影響を示す。
  • 利用者のアカウントによる物品の購入
  • 利用者の退会処理
  • 利用者のアカウントによる掲示板への書き込み
  • 利用者のパスワードやメールアドレスの変更
『攻撃方法と影響』
  • 入力-実行パターンのCSRF攻撃:例としてパスワード変更画面を示す
    1. 利用者があるホームページにログインしている
    2. 攻撃者が罠を用意する
    3. 被害者が罠を閲覧する
    4. 罠のJavaScriptにより、被害者のブラウザ上で攻撃対象サイトに対し、新しいパスワードがPOSTメソッドにより送信される
    5. パスワードが変更される
  • 確認画面がある場合のCSRF攻撃:例としてメールアドレス変更時を示す
    1. hiddenパラメータでパラメータ受け渡ししている場合 このパターンは確認画面がない場合と同じで「入力-実行パターンのCSRF攻撃」と同じ攻撃を受ける
    2. セッション変数によりパラメータ受け渡ししている場合 このパターンでは、次の2段階の攻撃が必要になってくる
      1. 確認画面に対してメールアドレスをPOSTしてセッション変数にメールアドレスをセットする
      2. タイミングを見計らって実行画面を呼び出す
『脆弱性が生まれる原因』
  • form要素のaction属性にはどのドメインのURLでも指定できる →罠などのサイトからでも、攻撃対象サイトにリクエストを送信できるということ
  • クッキーに保管されたセッションIDは、対象サイトに自動的に送信される →罠経由のリクエストに対しても、セッションIDのクッキー値が送信されるので、認証された状態で攻撃リクエストが送信されるということ
『対策』
  • CSRF対策の必要なページを区別する
  • 正規利用者の意図したリクエストであることを確認する
  • 具体的な方法としては以下の3つがある
    1. 秘密情報(トークン)の埋め込み
    2. パスワードの再入力
    3. Refererのチェック
『CSRF攻撃への保険的対策』 重要な処理の実行後に、対象利用者の登録済みメールアドレスに対して、処理内容の通知メールを送信する →攻撃を受けた際に利用者が早期発見をし、被害を最小限にとどめることが出来る。

4−6 セッション管理の不備

第三者がセッションIDを知るための手段は次の3つ
  1. セッションIDの推測
  2. セッションIDの盗み出し 方法としては、
    • クッキー生成の際の属性の不備により漏洩する
    • ネットワーク的にセッションIDが盗聴される
    • クロスサイト・スクリプティングなどアプリケーションの脆弱性により漏洩
    • PHPやブラウザ等プラットフォームの脆弱性により漏洩
    • セッションIDをURLに保持している場合は、Refererヘッダから漏洩
  3. セッションIDの強制
推測可能なセッションID 攻撃は以下の順で行われる。
  1. 対象アプリケーションからセッションIDを集める
  2. セッションIDの規則性の仮説を立てる
  3. 推測したセッションIDを対象アプリケーションで試す
対策としては、 Webアプリケーション開発ツールが備えるセッション管理機構を利用する。 URL埋め込みのセッションID セッションIDをクッキーに保存せず、URLに埋め込ませる場合がある。 →Refererヘッダを経由して、セッションIDが外部に漏洩し、成りすまし原因になる場合がある。 漏洩する条件
  • URL埋め込みのセッションIDを使える
  • 外部サイトへのリンクがある。あるいはリンクを利用者が作成できる。
対策としては、 URL埋め込みのセッションIDを使わないためには、クッキーにセッションIDを保存するように設定する。 セッションIDの固定化 セッションIDの固定化攻撃は以下の順で行われる。
  1. セッションIDを入手する
  2. 被害者に対して、入手したセッションIDを強制する
  3. 被害者は標的アプリケーションにログインする
  4. 攻撃者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする
対策として、
  • セッションIDをURL埋め込みにしない
  • クッキーモンスター問題のあるブラウザを使わない
  • クッキーモンスター問題の発生しやすい地域型ドメインを使わない
  • クロスサイト・スクリプティング脆弱性をなくす
  • HTTPヘッダ・インジェクション脆弱性をなくす
  • その他、クッキーを書き換えられる脆弱性をなくす
があります。 しかし、これらを満たすことは困難である。 このため、セッションIDが外部から強制されることは許容し、セッションIDの固定化攻撃が行われても、セッションハイジャックは防ぐようにすることが一般的。

4-7 リダイレクト処理にまつわる脆弱性

オープンリダイレクタ脆弱性 『概要』 リダイレクトの中で、任意のドメインにリダイレクトできるものをオープンリダイレクタ。 →フィッシングという詐欺に悪用される可能性がある 『脆弱性が生まれる原因』
  • リダイレクト先のURLを外部から指定できる
  • リダイレクト先のドメインのチェックがない
どちらか一方の条件に当てはまらないようにすれば脆弱性はなくなる。 『対策』
  • リダイレクト先のURLを固定する
  • リダイレクト先のURLを直接指定せず番号指定する
  • リダイレクト先のドメインをチェックする
HTTPヘッダ・インジェクション 『概要』 リダイレクトやクッキー発行など、外部からのパラメータを元にHTTPレスポンスヘッダを出力する際に発生する。 『脆弱性が生まれる原因』 リダイレクト先URLやクッキー値として設定されるパラメータ中に改行を挿入した場合に、改行がそのままレスポンスとして出力されることが原因 『対策』
  1. 外部からのパラメータをHTTPレスポンスヘッダとして出力しない: 以下の方針に従うべきである。
    • リダイレクト先をURLとして直接指定するのではなく、固定にするが番号などで指定する
    • Webアプリケーション開発ツールの提供するセッション変数を使ってURLを受け渡す
  2. 次の2つを実施する。
    • リダイレクトやクッキー生成を専用APIにまかせる
    • ヘッダ生成するパラメータの改行文字をチェックする

4-8 クッキー出力にまつわる脆弱性

一般的に、セッション管理機構ではセッションIDのみをクッキーに保存し、 データ自体は、Webサーバのメモリやファイル、データベースなどに保存する。 一方、クッキーに保存すべきでないデータをクッキーに保存することにより脆弱性が生まれる。 このデータとは、書き換えられると困る情報で、ユーザIDや権限情報などが挙げられる。 クッキーのセキュア属性不備 クッキーにはSecureという属性(以下、セキュア属性と記述)があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバに送信される。 『攻撃手法と影響』 セキュア属性のないクッキーを盗聴する方法は以下の手順である。
  1. Fiddlerを起動しておく
  2. 上記ページを閲覧して、ブラウザにクッキーをセットする
  3. 罠ページをアクセスする
  4. 罠ページからのリクエストにクッキーがついていることをFiddlerで確認する
『脆弱性が生まれる原因』 原因はセキュア属性をつけていないことであるが、 セキュア属性をつけない主な原因は以下が挙げられる。
  • 開発者がセキュア属性について知らない
  • セキュア属性をつけるとアプリケーションが動かなくなる →そのアプリケーションはショッピングサイトのようなHTTPとHTTPSが混在するWebアプリケーション
セキュア属性がついていないセッションIDが盗聴された場合でも、トークンにセキュア属性を付けることで確実に暗号化されていればHTTPSのページはセッションハイジャックされることはない。

4-9 メール送信の問題

メールヘッダ・インジェクション脆弱性 メールヘッダ・インジェクションは宛先や件名などのメールヘッダを外部から指定する際に、改行文字を使ってメールヘッダや本文を追加・変更する手法。 メールヘッダ・インジェクション脆弱性は以下の通り。
  • 件名や送信元、本文を改変される
  • 迷惑メールの送信に悪用される
  • ウイルスメールの送信に悪用される
脆弱性の生まれる原因以下の通り。 ヘッダの各フィールドは改行で区切られているので、外部から指定するパラメータに改行を挿入できれば、新たなヘッダを追加できる。 この改行をアプリケーションがチェックしていない場合には、ヘッダや本文を追加・変更できることになる。 →つまり、これが脆弱性の生まれる原因 『対策』 メール送信にsendmailコマンドではなく、専用のライブラリを使用すべき。 その上で、以下のいずれかを実施する。
  • 外部からのパラメータメールヘッダに含ませないようにする
  • 外部からのパラメータには改行を含ませないようにメール送信時にチェックする

4-10 ファイルアクセスにまつわる問題

ディレクトリ・トラバーサル脆弱性 外部からパラメータの形でサーバ上のファイルを指定できるWebアプリケーションでは、ファイル名に対するチェックが不十分であると、アプリケーションの意図しないファイルに対して閲覧や改ざん、削除が出来る場合がある。 この脆弱性をディレクトリ・トラバーサルという。 影響は以下の通り。
  • Webサーバ内のファイルの閲覧→重要情報の漏洩
  • Webサーバ内のファイルの改ざんの削除 →Webコンテンツ改ざんによるデマ、誹謗中傷の書き込み →マルウェアのサイトに誘導する仕組みの書き込み →スクリプトファイルや設定ファイル削除によるサーバ機能停止 →スクリプトファイル改ざんによる任意のサーバスクリプト実行
脆弱性が生まれる原因は、
  • ファイル名を外部から指定することができる
  • ファイル名として、絶対パスや相対パスで異なるディレクトリを指定できる
  • 組み立てたファイル名に対するアクセスの可否をチェックしていない
対策は、
  • 外部からファイル名を指定してできる仕様を避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する
意図しないファイル公開 外部から閲覧されると困るファイルをWebサーバの公開ディレクトリに配置している場合がある。 この場合、ファイルに対するURLがわかると、秘密ファイルの閲覧が可能になる。 意図しないファイルの公開により重要情報の漏洩が発生する。 脆弱性が生まれる原因は、
  • ファイルが公開ディレクトリに置かれている
  • ファイルに対するURLを知る手段がある
  • ファイルに対するアクセス制限がかかっていない
根本的な対策としては、非公開ファイルを公開ディレクトリに置かないことである。 そのためには、
  • アプリケーションの設計時に、ファイルの安全な格納場所を決める
  • レンタルサーバを契約する場合は非公開ディレクトリが利用できることを確認する

4-11 OSコマンド呼び出しの際に発生する脆弱性

OSコマンド・インジェクション Webアプリケーションの開発に用いる言語の多くはシェル経由でOSコマンドを呼び出す機能を提供しており、シェルを呼び出せる機能の使い方に問題があると、意図しないOSコマンドが実行可能になる場合がある。 これがOSコマンド・インジェクションである。 典型的には以下のような攻撃を受ける。
  1. 攻撃用ツールを外部からダウンロードする
  2. ダウンロードしたツールに実行権限を与える
  3. OSの脆弱性を内部から攻撃して管理者権限を得る
  4. Webサーバは攻撃者の思い通りのままになる
上記を行うと以下の悪用が可能になる。
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別のサーバへの攻撃
この脆弱性が生まれる原因は、
  • シェル経由でOSコマンドを呼び出す際に、シェルのメタ文字がエスケープされていない場合
  • シェル機能を呼び出せる関数を仕様している場合
対策としてはいずれかを行うべきである。(優先すべき順に並べる)
  1. OSコマンド呼び出しを使わない実装方法を選択する
  2. シェル呼び出し機能のある関数の利用を避ける
  3. 外部から入力された文字列をコマンドラインのパラメータに渡さない
  4. OSコマンドに渡すパラメータを安全な関数によりエスケープ
万一対策に漏れがあった場合の影響が大きいため、攻撃の被害を軽減する保険対策を実施すべきである。
  • パラメータの検証
  • アプリケーションの稼働する権限を最小限する
  • WebサーバのOSやミドルウェアのバッチ適用

4-12 ファイルアップロードにまつわる問題

アップロード機能に対するDoS攻撃 Webアプリケーションのアップロード機能に対して、巨大なファイルを連続して送信することにより、Webサイトに過大な負荷を掛けるDoS攻撃を仕掛けられる可能性がある。 影響として、
  • 応答速度の低下
  • 最悪の場合、サーバの停止
対策としては、アップロードファイルの容量制限が有効である。 アップロードファイルによるサーバ側スクリプト実行 影響として、
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別サーバへの攻撃
アップロードファイルによるサーバ側スクリプト実行を防止するには以下を実施する。
  • 利用者にアップロードされたファイルは公開ディレクトリに置かず、スクリプト経由で閲覧させる
  • ファイルの拡張子をスクリプト実行の可能性のないものに制限する
脆弱性が生まれる原因は、
  • アップロードしたファイルが公開ディレクトリに保存される
  • アップロード後のファイル名として、「.php」、「.asp」などスクリプトを示す拡張子が指定できる
対策としては、上記の原因を潰せば良いわけですが、 拡張子の制限だけでは対策抜けが生じる可能性があるため、 ファイルを公開ディレクトリに保存しない方法が望ましい。 ファイルダウンロードによるクロスサイト・スクリプティング 攻撃者がアプリケーションに罠を仕掛けて、アップロードしたファイルがHTMLとして認識されるような仕向ける。 利用者のブラウザがこのファイルをHTMLとして認識するとXSS攻撃が成立する。 脆弱性の生まれる原因は、Internet Explorer特有の仕様が影響する。 ファイルダウンロードによるXSS脆弱性対策はファイルのアップロード時とダウンロード時の対策それぞれを示す。
  1. ファイルアップロード時の対策 以下を実施する。
    • 拡張子が許可されたものかをチェックする
    • 画像の場合は、マジックバイトも確認する
  2. ファイルダウンロード時の対策 以下を実施する。
    • Content-Typeを正しく設定する
    • 画像を場合は、マジックバイトを確認する
    • 必要に応じてContent-Dispositionヘッダを設定する
  3. その他の対策
    • ファイルサイズ以外の縦横サイズ、色数などのチェック
    • 画像として読み込めるかどうかのチェック
    • ウイルス・スキャン
    • コンテンツの内容チェック →アダルトコンテンツ →著作権を侵害するコンテンツ →法令、公序良俗に反するコンテンツ

4-13 インクルードにまつわる問題

ファイルインクルード攻撃 includeなどに指定するファイル名を外部から指定できる場合、アプリケーションが意図しないファイルを指定することにより脆弱となる場合がある。 →ファイルインクルード脆弱性 影響は以下の通り。
  • Webサーバ内のファイルの閲覧による情報漏洩
  • 任意のスクリプトの実行による影響 →サイト改ざん →不正な機能実行 →他サイトへの攻撃
脆弱性が生まれる原因は、
  • インクルードファイル名を外部から指定することが出来る
  • インクルードすべきファイル名かどうかの妥当性をチェックしていない
である。 対策は以下のいずれかを実施する。
  • 外部からファイル名を指定することを避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する

4-14 evalにまつわる問題

evalインジェクション eval関数の利用法に問題がある場合、外部から送り込んだスクリプトを実行される場合がある。 →このような攻撃をevalインジェクション攻撃 この攻撃による影響は、
  • 情報漏洩
  • サイト改ざん
  • 不正な機能実行
  • 他サイトへの攻撃
がある。 脆弱性が生まれる原因は、
  • evalを用いることがそもそも危険である
  • evalに与えるパラメータのチェックがされていない
である。 対策としては、上記の原因からもわかる通り、
  • evalを使わない
  • evalの引数に外部からのパラメータを指定しない
  • evalの与える外部からのパラメータを英数字に制限する

4-15 共有資源に関数問題

競合状態の脆弱性 共有資源とは、複数のプロセスやスレッドから同時に利用している変数、共有メモリ、ファイル、データベースなどのこと。 共有資源に対する排他制御が不十分な場合、競合状態の脆弱性の原因となる場合がある。 代表例としては、
  • 別人の個人情報などが画面に表示される
  • データベースの不整合
  • ファイルの内容の破壊
が挙げられる。 脆弱性の生まれる原因は、
  • 変数nameは共有変数である
  • 共有変数nameの排他制御をしていない
対策は以下のうちいずれかの実施である。
  • 可能であれば共有資源を使用しない
  • 共有資源に対して排他制御を行う
まとめ だいぶだらだらと長く記述していきましたが、 それぞれの脆弱性の発生原因とそれへの対策をしっかりと抑えていく必要があると感じた。 現状、覚えられていない。とりあえず、このような脆弱性があるのだなという把握は必要。

第5章 代表的なセキュリティ機能

5−1 認証

認証:利用者が確かに本人であることをなんらかの手段で確認すること。 Webアプリケーションで用いられる認証手段は、「HTTP認証」、「HTMLフォームでのIDとパスワードを入力させるフォーム認証」、「SSLクライアント証明書を用いるクライアント認証」がある。 それでは、認証処理を要素分解していく。
  1. ログイン機能:認証処理の中心となるのが本人確認の機能=ユーザIDとパスワードをデータベースとの照合
    • ログイン機能に対する攻撃
      • SQLインジェクション攻撃による認証機能のバイパス・パスワードの入手
      • ログイン画面に対するパスワード試行
      • ソーシャルハッキングによるパスワード入手
      • フィッシングによるパスワード入手
    • ログイン機能が破られた場合の影響:Webアプリケーションが不正ログインされると、攻撃者は利用者の持つ権限を全て利用できるようになる。
    • 不正ログインを防ぐためには →SQLインジェクションなどのセキュリティバグをなくす →パスワードを予測困難なものにする
  2. 総当たり攻撃への対策:アカウントロックが有効である。 →暗証番号やパスワードを規定回数以上間違えるとアカウントをロックする
  3. パスワードの保存方法
    • パスワードの保護の必要性:パスワードの漏洩→他の秘密情報の漏洩→悪用により情報漏洩以外の被害
    • 暗号化によるパスワードと課題:暗号を使う場合の課題は以下の通り
      1. 安全な暗号のアルゴリズムの選定
      2. 鍵の生成
      3. 鍵の保管
      4. 暗号アルゴリズムが危殆化した場合の再暗号化
    • メッセージダイジェストによるパスワード保護と課題 メッセージダイジェスト・・・任意の長さのデータを固定長のデータ(メッセージダイジェスト)に圧縮する関数をハッシュ関数といい、セキュリティ上の要件を満たすハッシュ関数を暗号学的ハッシュ関数という。 それでは、メッセージダイジェストを用いてパスワードを保護する。 まず、ハッシュ関数の特性は、
      • ハッシュ値から元データを得ることが困難(一方向性)
      • 異なる入力から得られるハッシュ値が一致する確率が極めて低い(衝突耐性)
      であり、これによりパスワードが安全に保存できる。 しかし、ハッシュ値から元のパスワードを解析するための手法がしられている。 3種類取り上げる。
      1. オフライン総当たり攻撃:パスワードは短い文字列で文字種も限られていることから総当たり的にデータを探索できる
      2. レインボー・クラック:レインボーテーブルというものを用いて文字種と文字数の制限毎に作成される →文字数を多くすることで防ぐことができる
      3. ユーザDB内にパスワード辞書が作られる:攻撃者がダミーのユーザを多数登録して、ユーザDB上に「パスワード辞書」を作ってしまう
    • ハッシュ解読の対策として2つ示す。
      1. ソルト:ハッシュの元のデータに追加する文字列のこと。 →見かけのパスワードを長くするとともに、ソルトをユーザ毎に異なるものにすることで、パスワードが同じでも異なるハッシュ値が生成される
      2. ストレッチング:ハッシュの計算を繰り返し行うことによって計算時間をのばすことが出来る
  4. 自動ログイン
    • 自動ログインの安全な実装方式:
      • セッション寿命を延ばす
      • トークンを使う
      • チケットを使う
      • 3方式の比較を行うと、 この中ではトークン方式が一番好ましい。 メリットとして、
        • 自動ログインを選択しない利用者に影響を与えない
        • 複数端末からログインしている場合に一斉ログアウトできる
        • 管理者が、特定利用者のログイン状態をキャンセルできる
        • クライアント側に秘密情報がわたらないので解析されるリスクがない
    • 自動ログインのリスクを低減するには:重要な処理の前にはパスワード入力を要求する
  5. ログインフォーム:一般的なガイドラインは以下の通り
    • パスワード入力欄はマスク表示する
    • HTTPSを利用する場合は、ログインフォームからHTTPSにする
  6. エラーメッセージの要件:エラーメッセージは攻撃者のヒントとなる情報は含むべきでない
  7. ログアウト機能:ログアウト処理の要件は以下の通り
    • ログアウト処理は副作用があるのでPOSTメソッドでリクエストする
    • ログアウト処理ではセッションを破棄する
    • 必要な場合、CSRF対策の対象とする

5-2 アカウント管理

アカウント管理における6つの機能についてセキュリティ上の注意点を記述する
  1. ユーザ登録:ユーザ登録については4つのセキュリティ上の注意点がある。
    1. メールアドレスの受信確認:メールアドレスを登録・変更する際には、登録されたメールアドレスに送信されるメールを利用者自身が受信できることを確認すべき そのために→
      • メールにトークンつきURLを添付して、そのURLから処理を継続する
      • メールアドレスを入力した後、トークン入力画面に遷移する。 トークンは、指定したメールアドレスにメール送信される
    2. ユーザIDの重複防止:ユーザIDは一意でなければならない為、排他的制御に細心の注意を払う必要がある
    3. ユーザの自動登録への対処:インターネット経由で自由にユーザ登録できるWebサイトの場合、外部からの自動操作により大量にユーザを作成される場合がある。 →CAPTCHAという仕組みを用いて、わざと文字をゆがめた画像を表示させ、利用者に文字を入力させ人間であることを確認する方法がある。
    4. パスワードに関する注意
  2. パスワードの変更:パスワード変更機能に対するセキュリティ上の注意点は以下の4点
    1. 現在のパスワードを確認する:現在のパスワードを入力してもらい照合 →セッションハイジャックされた状態で第三者がパスワードを変更することを防止できる
    2. パスワード変更時にはメールでその旨を通知する:第三者が不正にパスワードを変更した場合でも早期発見に繋がる
    3. SQLインジェクション脆弱性:
    4. CSRF脆弱性
  3. メールアドレスの変更:メールアドレス変更に必要な機能対策は以下の3つ
    • 新規メールアドレスに対する受信確認
    • 再認証
    • メール通知
  4. パスワードリマインダ:パスワードを忘れた際に何らかのかたちでパスワードを知らせる仕組みを用意する場合がある。 これには、管理者向けパスワードリマインダと利用者向けパスワードリマインダがある。 利用者向けパスワードリマインダの方法は以下の4つ
    • 現在のパスワードをメールで通知する
    • パスワード変更画面のURLをメールで通知
    • 仮パスワードを発行してメールで通知
    • パスワード変更画面に直接遷移
    この中で推奨すべきは下の2つである。
  5. アカウントの停止:特定のアカウントに対してセキュリティ上の問題が生じた場合は当該のアカウントを一時的に停止する場合がある。
  6. アカウントの削除:アカウントの削除は通常取り消し出来ない処理なので、本人の意思確認とCSRF脆弱性対策を目的として、パスワードの確認を要求すべき

5-3 許可

許可とは、認証された利用者に対して権限を与えること。 権限の例を以下に示す。
  • 認証された利用者のみ許可された機能 →退会処理、送金、新規ユーザ作成等
  • 認証された利用者のみに許可された情報の閲覧 →非公開の利用者自身の個人情報、非公開の掲示板、Webメール等
  • 認証された利用者のみに許可された編集操作 →利用者本人の設定変更、Webメールからのメール送信等

5-4 ログ出力

ログ出力の目的
  • 攻撃や事故の予兆をログから把握し、早期に対処する
  • 攻撃や事故の事後調査
  • アプリケーションの運用監査
アプリケーションログは以下の3種類である。
  • エラーログ:エラーを記録するもの →攻撃の検出に役立つ場合がある
  • アクセスログ:Webアプリケーションの情報閲覧や機能の利用記録をしてのログ →正常・異常共にログを残し、個人情報漏洩事件・事故への対応に役立つ
  • デバッグログ:デバッグ用のログ →開発環境やテスト環境で取得するもので、本番環境では取得すべきでない

第6章 文字コードとセキュリティ

6-1 文字コードとセキュリティの概要

文字コードとは以下の2つの概念を合わせたものである。
  • 文字集合
  • 文字エンコーディング

6-2 文字集合

文字集合とは、その名の通り文字を集めたもの。 文字集合の扱いが原因でおこる脆弱性は、文字変換の際のエスケープ処理で脆弱性が生まれる。

6-3 文字エンコーディング

文字エンコーディングとは、文字集合をコンピュータ上で扱う為の符号化。 文字エンコーディングは以下のようなものがある。
  • Shift_JIS
  • ISO-2022-JP
  • UTF-16
  • UTF-8

6-4 文字コードによる脆弱性の発生要因まとめ

文字コードによる脆弱性については以下の3つのタイプに分類される。
  • 文字エンコーディングとしては不正なバイト列による脆弱性
  • 文字エンコーディングの扱いの不備による脆弱性
  • 文字集合の変更に起因する脆弱性

6-5 文字コードを正しく扱うために

文字コードを正しくあつかうためには、以下の4つのポイントがある。
  1. アプリケーション全体を通して文字集合体を統一する
  2. 入力時に不正な文字エンコーディングをエラーにする
  3. 処理の中で文字エンコーディングを正しく扱う
  4. 出力時に文字エンコーディングを正しく扱う

第7章 携帯電話向けWebアプリケーションの脆弱性対策

7-1 携帯電話向けWebアプリケーションの技術的特徴

携帯電話のブラウザでWebアクセスする際は、キャリアのゲートウェイからインターネットに説ゾオクされる形態となる。 ゲートウェイの役割は以下の通り。
  • 携帯電話網からインターネットへの橋渡し(プロキシ)
  • 携帯IDの付与
  • クッキー保持
  • 絵文字の変換
  • SSL処理
  • 言語変換
ブラウザの機能的特徴
  • クッキーが使えない端末の存在:セッション管理にクッキーを用いず、URLにセッションIDを埋め込む方式が定着
  • JavaScriptが使えない端末が大半
  • Refererなどのリクエストヘッダの制限
  • HTTPレスポンスの容量制限

7-2 携帯ブラウザの技術仕様

JavaScriptのサポートにより脆弱性が¥が存在する場合のリスくが高まるとともに、新たな脆弱性パターンが生まれる可能性もある。 クッキーの仕様を以下に示す
  • HTTPの状態でSet-Cookieされたクッキーは事業者のゲートウェイが保持する
  • HTTPSの状態でSet-Cookieされたクッキーは端末が保持する

7-3 かんたんログインの問題

かんたんログインとは、IDとパスワードの代わりに端末IDのみを用いた認証方法。 かんたんログインに対する攻撃手法を以下に示す。
  • 携帯電話をモデムとしてゲートウェイを経由する方法
  • リクエストヘッダを書き換える
  • DNSリバインディング攻撃(受動的攻撃)
上記に攻撃手法を示したが、安全なかんたんログインの実装方法はあるのか 以下が必須条件となる
  • 携帯電話事業者のゲートウェイからのアクセスのみを受け付ける
  • リモートIPアドレスを元に事業者判定する
  • 携帯IDとしてはiモードID、EZ番号、ユーザIDのみ用いる
  • HTTPSではかんたんログインを受け付けない
  • Hostヘッダのチェックまたは名前ベースのバーチャルホストの設定を行う
  • ソフトバンクの非公式JavaScript対応端末へのなんらかの対処を行う

7-4 URL埋め込みのセッションIDによる問題

Refererヘッダにより外部にセッションIDが漏洩するという問題がありますが、それ以外にも以下の問題がある。 ・セッションIDの固定化がおこりやすい 対策としては、
  • クッキーが使え得る場合はクッキーを使う
  • 外部ドメインに極力リンクしない
  • 外部リンクにはクッションページをはさむ
  • ログイン後にセッションを開始する
  • 検索エンジン対策:認証前はセッションに有効にしないこと。

第8章 Webサイトの安全性を高めるために

Webサーバへの攻撃経路と対策

Webサーバへの攻撃はソフトウェアの脆弱性をついた攻撃や、Webサーバの管理に用いるパスワード攻撃がある。 対策としては、
  • サービス提供に不要なソフトウェアは稼働させない:不要なソフトウェアについては削除か停止をすることが安上がりで安全
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制御する
  • 認証強度を高める:管理者のソフトウェアの認証の強度を高める →以下を推奨
    • TelnetサーバとFTPサーバを削除あるいは停止し、SSH系サービスのみを稼働させる
    • SSHサーバの設定によりパスワード認証を停止し、公開鍵認証のみとする

8-2 成りすまし対策

成りすましの手口はネットワーク的な成りすましと、Webサイトのデザインだけを似せたフィッシングの手法がある。
  1. ネットワーク的な成りすまし
    • DNSに対する攻撃:
      • DNSサーバに対する攻撃によりDNSの設定内容を書き換える
      • DNSキャッシュボイズニング攻撃
      • 執行したドメインを第三者がく購入して悪用する
    • ARPスプーフィング:ARPの偽応答を返すことで、IPアドレスを偽装する手法
  2. フィッシング:正規サイトにそっくりな入力画面を用意してメールなどで利用者を誘導し、IDとパスワードや個人情報などを入力させて盗み取る手法
Webサイトの成りすまし対策として以下が有効である。
  • ネットワーク的な対策:
    • 同一セグメント内に脆弱なサーバは置かない
    • DNS運用の強化:DNSSECの導入
  • SSL/TLSの導入
  • 確認しやすいドメインの採用

8-3 盗聴・改ざん対策

盗聴・改ざんの経路を以下に示す。
  • 無線LANの盗聴・改ざん:無線LANを流れるパケットは適切に暗号化されていないと盗聴される可能性がある
  • ミラーポートの悪用
  • プロキシサーバの悪用:もともとあるプロキシサーバを操作できる場合や、通信路上にプロキシサーバを設置出来る場合、プロキシサーバを流れるHTTPメッセージを盗聴できる
  • 偽のDHCPサーバ:偽のDHCPサーバにより、DNSやデフォルトゲートウェイのIPアドレスを偽装できる場合がある
中間者攻撃:盗聴用の機器により通信を中継させるタイプのものがある。 通信の盗聴・改ざんの対策として、以下の注意点がある。 SSL利用時の注意点
  • 入力画面からHTTPSにする
  • クッキーのセキュア属性に注意
  • 画像やCSS、JavaScriptなどもHTTPSで指定
  • frame、iframeを使わない
  • ブラウザのデフォルト設定でエラー表示されないようにする
  • アドレスバー・ステータスバーを隠さない
  • コンテキストメニューを無効化しない

8-4 マルウェア対策

Webサイトのマルウェア対策とは、以下の2つの意味がある
  • Webサーバがマルウェアに感染しないこと→マルウェアがWebサーバ上で活動してる状態
  • Webサイトを通じてマルウェアを公開しないこと→Webコンテンツとしてマルウェアがダウンロード出来る状態
マルウェアの感染経路は、インターネット接続・外部媒体、持ち込みクライアント・電子メールが多い。 Webサーバのマルウェア対策は以下が重要
  • サーバの脆弱性をタイムリーに行う
  • 出所不明なプログラムをサーバに持ち込まない
  • サーバ上では運営に直接関係ない操作をしない
  • サーバにUSBメモリなどの外部メディアを装着しない
  • Webサーバのネットワークを執務スペースのLANと切り離す
  • サーバに接続するクライアントPCにウイルス対策ソフトを導入してパターンファイルを最新に保つ
  • クライアントPCに最新のセキュリティパッチを導入する

第9章 安全なWebアプリケーションのための開発マネジメント

安全なアプリケーションのための開発プロセスについて説明する
  • 企画段階の留意点 安全なアプリケーション開発に必要な予算の見積もり、確保することが重要
  • 発注時の留意点 RFPに記載するセキュリティ要件が重要になってくる →セキュリティバグに対する要求は漠然としてしまうと実効性に乏しくなってしまう。
  • 要件定義時の留意点 セキュリティバグ対策については受注者の開発基準をベースとすべきである。
  • 基本設計の進め方 実施すべき重要項目は以下の通り
    1. セキュリティ機能に対する具体化
    2. 方式設計として開発標準の詳細化、テスト方式の決定
    3. 画面設計時のセキュリティ機能の確認
  • 詳細設計・プログラミング時の留意点 基本設計に従って開発
  • セキュリティテストの重要性と方法 自力で診断する場合は「ウェブ健康診断仕様」という脆弱性診断を用いて判断する。
  • 受注者側テスト 以下の手法を行う
    • ソースコード検査
    • ツールによるブラックボックス検査
    • 手動によるブラックボックス検査
  • 発注者側テスト 予算に余裕がなければ先ほど出てきた「ウェブ健康診断仕様」を用いて行う。
  • 運用フェーズの留意点 このフェーズで重要なことは以下の2点
    • ログの監視
    • 脆弱性対処
以上で備忘録を終了する。