前回、WEBアプリケーションにおけるセッション管理（１）ではセッションが何故必要なのかを学習をして来ました。
この記事ではシステム要件定義者や各企業WEB担当者に向けたアーキテクトの基礎について学習していく記事になっています。
またエンジニア経験者でもっと自分ができる事を増やしたい方、若しくは全くの未経験の方でも学べる様に分かりやすく解説して行きます。
１、セッションが企業やサービスにもたらす危機的なダメージ
前回の記事ではセッションとしてどんなデータを保持するのかで終わりました。
・取り組み中の業務データ
・ログイン情報
上記のデータ管理の仕方で重大な事件を引き起こす恐れがある事をお伝えします。
１−１、セッションの盗難によるインシデント
インシデントとは事故のことです。
ここで盗まれるのがcookieに格納されたセッションになります。
このセッションをクラッカーが自分の通信に乗せてサーバーにアクセスをすれば、ログインが出来てしまいます。
クラッカーがユーザーのセッションIDを使うことによって個人情報の流出が起こってしまいます。
またセッションIDはChromの検証ツールで確認が出来ます。
セッションIDは赤く塗りつぶしている部分になります。
検証ツールでのセッション確認の仕方はこちらから確認してください。
（ページ作成中）
１−２、セッションの管理が招く性能の低下
一つのアプリケーションはスケールアウトと言ってサーバーを複製して性能アップを図ることがあります。
サーバーを複製してアクセスを分散させます。
そこで発生する問題は、セッションの管理の仕方によってアクセス時の負荷が増えてしまうと言う点です。
セッションをサーバーで管理する場合、各サーバーでセッションのレプリケーションが必要になります。
それがボトルネックになり性能の向上が妨げられと言う状況です。
１−３、まとめ
このセッションでのまとめ問題
・セッションが漏れることによって個人情報が漏れる仕組みは？
・サーバーアクセスの負荷低減で取り組むサーバーの複製をなんて言う？
・セッションをAPサーバーで管理することによって生じる負荷を説明してください。
ぜひ質問や聞いてみたいことがあればコメントを貰えると嬉しいです。
次は今日説明した問題を解決するためのセッション管理を学んで行きます。
（インシデントを避けるセッション管理方：作成中）
この記事のソフトウェアエンジニアリングに関わるすべての人の最低限の知識のトップページは以下のURLになります。
（改良中）ソフトウェアエンジニアリングに関わる全ての人の最低限の常識を再度学習してみた（１）