nginxを動かしてみる part3 -クライアント認証対応-

1.概要

サーバSSL対応に続き、クライアント証明書認証を試した時の備忘録

2.実行環境

ubuntu version 18.04 TLS
nginx version: nginx/1.14.0 (Ubuntu) built with OpenSSL 1.1.1 11 Sep 2018 OpenSSL 1.1.1 ※ユーザー証明書発行に必要

3.ユーザー証明書の発行

ユーザー証明書用の秘密鍵を作成

#mkdir ./client_certificate
#cd  ./client_certificate
#openssl genrsa -aes256 -out key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
...............................................................+++++
.............................+++++
e is 65537 (0x010001)
Enter pass phrase for key.pem:
Verifying - Enter pass phrase for key.pem:

ユーザー証明書要求を作成

openssl req -new -key user1.key -out user1.csr
Enter pass phrase for user1.key:
Can't load /root/.rnd into RNG
140210030563776:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Komae
Organization Name (eg, company) [Internet Widgits Pty Ltd]:company,inc.
Organizational Unit Name (eg, section) []:system
Common Name (e.g. server FQDN or YOUR name) []:user1
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

ユーザー証明書に署名

openssl x509 -req -days 365 -in user1.csr -CA /etc
/nginx/server_cert/example.pem -CAkey /etc/nginx/server_cert/key.pem -set_serial 01 -out user1.pem
Signature ok
subject=C = JP, ST = Tokyo, L = Komae, O = "company,inc.", OU = system, CN = user1
Getting CA Private Key
Enter pass phrase for /etc/nginx/server_cert/key.pem:

pfk12形式に変換

penssl pkcs12 -export -out user1.pfx -inkey user1.key -in user1.pem -certfile /etc/nginx/server_cert/example.pem
Enter pass phrase for user1.key:
Enter Export Password:
Verifying - Enter Export Password:

ここまでで、証明書保管フォルダ(/etc/nginx/client_certificate)には以下のファイルが存在

• key.pem ※秘密鍵
• user1.pem　※証明書
• user1.csr　※証明書要求
• user1.pfx　※pfx形式の証明書

user1.pfxをHOST_OS側に転送しておきます。

4.nginxの設定

serverブロックを書き換えます。今回完全SSL化としますのでhttp⇒httpsへのリダイレクトの設定も行います。

/etc/nginx/sites-available/example.com

server {
       listen 80 default;
       return 308 https://$host$request_uri;
       }

server {

        listen 443 ssl;

        server_name  example.com;
        root /var/www/html/;

        ssl_certificate /etc/nginx/server_cert/example.pem;
        ssl_certificate_key /etc/nginx/server_cert/key.pem;
        ssl_password_file /etc/nginx/server_cert/key_pass;
        ssl_protocols  TLSv1.1 TLS1.2;
        ssl_ciphers   "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;

        ssl_client_certificate /etc/nginx/server_cert/example.pem;  #追加
        ssl_verify_client on;　※追加
#       ssl_verify_depth 1
#       ssl_crl

        location / {
               index index.html;
       }

       location /page1 {
               root /var/www/html_tmp/;
               index index.html;
       }
       location /page2 {
               root /var/www/html_tmp/;
               index index.html;
       }

}

--ssl_client_certificate--
認証局証明書の指定です。今回は自己署名証明書を指定しています。

--ssl_verify_client --
クライアント署名を有効化

--ssl_verify_depth--
サーバがクライアントの身元を確認するために証明書のチェーンを何階層までたどるかを設定。中間CA等を利用する場合。
※今回は使用しない。

--ssl_crl--
証明書の失効確認を行う場合には指定。 crlは定期的に更新する必要がある。
※今回は使用しない。

5.nginxを起動

nginxを再起動し、example.comへ変更を適用します。

systemctl restart nginx.service

起動確認のためホストOSから接続をしてみます。

• 証明書なしで接続をしてみる。

• 証明書をインストールした後に接続をしてみる。

使用する証明書の確認がブラウザ上で表示される⇒OK

サイトに接続される。

6.まとめ

実際に利用する場合は、接続端末の紛失や、社員退職等による証明書失効確認を行う必要があり、CRLやOCPSとの連携も必要。 機械があれば試してみる。

7.参考リンク

究極のノマドを追求したらカギっ子管理者になってたオレオレ証明書の巻！！ - Qiita

Nginxでクライアント証明書による認証を行う - Qiita

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

nginxを動かしてみる part2 -サーバSSL対応-

1.概要

初期設定の続き。サーバーのSSL化を試した時の備忘録 httpブロックでSSLバージョンの指定を行い、serverブロックでSSLの受け入れポートと使用する証明書の指定を行う。

2.実行環境

ubuntu version 18.04 TLS
nginx version: nginx/1.14.0 (Ubuntu) built with OpenSSL 1.1.1 11 Sep 2018 OpenSSL 1.1.1 ※自己証明書発行のため

3.自己証明書の準備

自己署名用の秘密鍵の作成

#mkdir /etc/nginx/server_cert　#証明書保管フォルダ作成
#cd /etc/nginx/server_cert
#openssl genrsa -aes256 -out key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
..........+++++
.........+++++
e is 65537 (0x010001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:

サーバ用の自己署名書を作成

# openssl req -new -x509 -days 365 -key ./key.pem -out example.pem

Enter pass phrase for ./key.pem:
Can't load /root/.rnd into RNG
139655662956992:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Shinjuku
Organization Name (eg, company) [Internet Widgits Pty Ltd]:company,inc.
Organizational Unit Name (eg, section) []:system
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []: #空白

-x509オプションをつけて自身で作成した秘密鍵を署名しています。なので自己署名と呼ばれます。通常は認証局に申請し、認証局の鍵で署名します。

秘密鍵パスワードファイルの作成

echo password > ./pass

ここまでで、証明書保管フォルダ(/etc/nginx/server_cert)には以下のファイルが存在

• key.pem ※秘密鍵
• example.pem　※自己署名証明書
• pass ※秘密鍵のパスワードファイル

Tips!
nginxは秘密鍵にパスフレーズが設定されている場合は以下のエラーが出力されます。

nginx[5240]: Enter PEM pass phrase:
nginx[5240]: nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/server_cert_tmp/key.pem") failed (SSL: error:2807106B:UI routines:UI_process:process
nginx[5240]: nginx: configuration file /etc/nginx/nginx.conf test failed

対策としては以下の2つになります。
１．パスフレーズを記載したファイルを作成し読み込む
２．秘密鍵のパスワードを外す↓
https://rms.ne.jp/sslserver/basis/decrypt_key/

4.nginxの設定

serverブロックを書き換えます。今回完全SSL化としますのでhttp⇒httpsへのリダイレクトの設定も行います。

/etc/nginx/sites-available/example.com

server {
       listen 80 default;
       return 308 https://$host$request_uri;
       }

server {

        listen 443 ssl;

        server_name  example.com;
        root /var/www/html/;

        ssl_certificate /etc/nginx/server_cert/example.pem;
        ssl_certificate_key /etc/nginx/server_cert/key.pem;
        ssl_password_file /etc/nginx/server_cert/key_pass;
        ssl_protocols  TLSv1.1 TLS1.2;
        ssl_ciphers   "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;

        location / {
               index index.html;
       }

       location /page1 {
               root /var/www/html_tmp/;
               index index.html;
       }
       location /page2 {
               root /var/www/html_tmp/;
               index index.html;
       }

}

--ssl_certificate--
SSLサーバ証明書ファイルを指定します。

--ssl_certificate_key--
SSLサーバ証明書の秘密鍵ファイルそ指定します。

--ssl_password_file--
秘密鍵のパスフレーズを記載したファイルを指定します。

--ssl_protocols--
受け付けるSSLバージョンを指定します。

--ssl_ciphers--
使用可能なセキュリティスイートを指定します。Mozilla wikiにreccomendが記載されていましたので参考にしました。

--ssl_session_cache shared-- SSLセッションキャッシュの設定です。ハンドシェイクの情報をキャッシュし再利用することでサーバの負荷を軽減可能です。サーバリソースに不安がある場合は設定をお勧め。

--ssl_session_timeout--
SSLセッションのタイムアウトの時間です。

5.nginxを起動

nginxを再起動し、example.comへ変更を適用します。

systemctl restart nginx.service

起動確認のためホストOSから接続をしてみます。

• リダイレクトの確認 http://<サーバIPアドレス>/page1/ に接続。 nginx側から308リターンを返していて、Locationヘッダーにリダイレクト先がセットされています。その後SSLのハンドシェイクが始まっています。

• SSL化の確認 http://<サーバIPアドレス>8081/page1/ に接続。 無事SSL化されました。ちなみに自己証明書なので、通常はセキュリティ警告が表示されます。前もってnginxのサーバー証明書をHOST側にエクスポートし、"信頼済みルート署名書"として証明書をインポートしています。あと、Hostsファイルにexample.comを追記。　　

6.まとめ

SSL化を行う上では、受け入れるSSLバージョンの指定、暗号セキュリティースイートの指定を考慮したほうが良い。この辺はガイドライン等も出ているので参考にしながら機会があれば本実装したい。

7.参考リンク

自己署名証明書の作成 - Qiita

https://www.cryptrec.go.jp/report/archives/cryptrec-gl-3001-1.0.pdf

Security/Server Side TLS - MozillaWiki

nginxを動かしてみる part1 -初期設定-

1.概要

nginxを自身の環境へインストールし動作させてみたときの備忘録です。
雰囲気で触ることはあったが、改めて復習を兼ねて。

2.実行環境

ubuntu version 18.04 TLS
nginx version: nginx/1.14.0 (Ubuntu) built with OpenSSL 1.1.1 11 Sep 2018

上記サーバはwindows10pro のHyper-V環境で動作。

3.各種インストール

nginxのインストールは以下のブログを参考にさせていただきました。

nginxインストール
UbuntuにNginxをインストールする - Qiita

4.nginxの設定

nginxフォルダ構成

   ├ nginx 
       ├ nginx.conf   ※nginxの設定ファイル
       ├ sites-available
       ├      └ example.com　※vhostファイル
       └  sites-enable
              └ example.com (Link)　※vhostのリンク
 var/log
　└ nginx 
    ├access.log      ※アクセスログ
    └error.log　※エラーログ

nginx.confファイルの変更

ほぼデフォルトの設定ですが主要ポイントを記述

コアモジュールの編集

nginxのプロセスの制御を記述するブロック

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

--worker_proccess--
nginxのプロセス数を指定します。 nginxは１プロセスは１スレッドしか利用しないようです。 プロセス数はサーバコア数以下を指定する必要がありますが、autoとしておくことで自動で割り当ててくれます。

イベントモジュールの編集

ユーザーからの接続数を制御するブロックです。

events {
        worker_connections 768;
        # multi_accept on; 　#コメントアウト
        multi_accept on;　#onに変更
}

--worker_connections--
nginxのプロセスで同時に保持できるコネクション数です。

--multi_accept on--
同時にコネクションを受け付けることができるようになります。onに変更

httpモジュールの編集

ここからが実際のWebサーバ動作に関する記述です。 nginxのhttpモジュールは3つのブロック(http, server, location)で記述しその中にはディレクティブという命令を記述。各ブロックは{}で囲われます。

httpブロック
httpブロックは複数のserverブロックを持つことができ、全体に影響するディレクティブを記述します。
記述した設定はserverブロックで上書きできます。

serverブロック
serverブロックには稼働させるサーバ(仮想ホスト)ごとの固有のディレクティブを記述します。 複数のlocationブロックを持つことができます。

locationブロック
公開するコンテンツパスに適用するディレクティブを記述します。

• ベースセッティング

http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;

特に変更はしていません。
include /etc/nginx/mime.types 内にnginxで扱えるファイルの拡張子が記載されています。この中にないものは.octet-stremとして扱われるようです。

• SSLセッティング

##
# SSL Settings
##
#ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  #コメントアウト
ssl_protocols TLSv1.1 TLSv1.2;  #追加
ssl_prefer_server_ciphers on;

--ssl_protocols--
対応するSSLバージョンを指定します。対応するもののみ記述します。TLS1は脆弱なので、無効にしました。

• ログセッティング

##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

ログの変更先を指定します。デフォルトのままです。

• 圧縮セッティング

##
# Gzip Settings
##

gzip on;

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

レスポンスのコンテンツを圧縮するかの指定です。デフォルトです。

• 仮想ホストセッティング

##
# Virtual Host Configs
#

#include /etc/nginx/conf.d/*.conf;　#コメントアウト
include /etc/nginx/sites-enabled/*;

serverブロックは別のファイルで記述をし、読み込み先を指定するのがスタンダードのようです。 初期状態では読込先(include)が2行書かれており、先に記述してあるものが優先されるので、/etc/nginx/conf.d/*.conf を読み込む指定になっています。現在は、/etc/nginx/sites-enabled/* から読み込むのほうが主流となっているようです。

仮想サーバ設定ファイルを作成

serverブロックを記述したファイルを/etc/nginx/sites-available/フォルダに作成します。今回はexample.comという名前で作成。

server {

       listen 8081 default_server;
       server_name  example.com;
       root /var/www/html/;

       location / {
               index index.html;
       }

       location /page1 {
               root /var/www/html_tmp/;
               index index.html;
       }
       location /page2 {
               root /var/www/html_tmp/;
               index index.html;
       }

}

--listen---
接続を受け入れるIPアドレス、ポートを指定します。 本来の指定としては <ipアドレス>：<ポート>の指定になります。
省略した場合は、ipアドレスは0.0.0.0(すべて)、ポートは80になります。
※例
listen 80 == listen 0.0.0.0:80 　(port80で全てのサーバIPで待ち受ける) listen 192.168.1.1 == listen 192.168.1.1:80 　(port80で192.168.1.1アドレスで待ち受ける)

--server_name--
サーバ名になります。ここは実際に使用する名前を入れる必要があります。クライアントのhttpリクエストヘッダ内のhost情報を比較し、一致するserverブロックが適用されるためです。 複数のserverブロックを記述しており、どれにも一致しない場合に適用するserverブロックを明示的に指定することが推奨されており、指定するためにはlistenディレクティブにdefault-serverという記述を追加します。

--locationブロック-- 実際に公開するコンテンツパスに対するディレクティブを記述します。 今回は簡単なテストのため、書くパスごとのルートディレクトリ指定と、indexファイルの指定をしています。
※http://example.com/page1 or page2 で接続した場合に異なるindex.htmlを返します。

仮想サーバ設定の有効化

作成したexample.comを有効化します。
/etc/nginx/sites-enable/の下にexample.comファイルのリンクを作成します。

ln -s /etc/nginx/sites-available/example.com.com /etc/nginx/sites-enable/example.com

nginx設定ファイルの設定チェック

変更及び作成をした設定ファイルが正しい状態かをチェックする機能が提供されています。

• 正しい場合

root@ubuntu1804:/etc/nginx# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

• 誤りがある場合

root@ubuntu1804:/etc/nginx# nginx -t
nginx: [emerg] unknown directive "sss" in /etc/nginx/sites-enabled/example.com:6
nginx: configuration file /etc/nginx/nginx.conf test failed

5.nginxを起動

• nginxを再起動し、example.comを有効化します。

systemctl restart nginx.service

• 起動確認のためホストOSから接続をしてみる

http://<サーバIPアドレス>8081/page1/ に接続。

・http://<サーバIPアドレス>8081/page2/ に接続。

6.nginxの初期設定を終えてみて

特に大きくつまずくところはなく、ちゃんと動いてくれました。初期設定では特に細かな設定は入れていませんので、一般的に利用用途がありそうなアクセス制御機能や認証機能、リバースプロキシ機能などの動作確認をしようと思っています。

7.参考リンク

nginx連載3回目: nginxの設定、その1 - インフラエンジニアway - Powered by HEARTBEATS

nginx ドキュメント 日本語訳

NetFlow 基本のKI

皆さんこんにちわ

ネットワークの可視化していますか？

クラウド、セキュリティ、SDNの流れから今ネットワークがどのように使われているのか？を知ることは非常に重要と感じています。といいますか可視化は当たり前のファンクションになってきています(ノД`)・゜・。

ということで、ネットワークの可視化について調べて自分なりに今風に実装をしていけたらと思いました。

まずは情報のソースとなるNetflowについて調べます。

Netflowとは？　

NetFlowは1996年ごろにシスコ製ルータに導入された機能で、インターフェイスに出入りするときにIPネットワークトラフィックを収集する機能を提供します。 NetFlowによって提供されたデータを分析することによって、ネットワーク管理者はトラフィックの発信元と宛先、サービスクラス、輻輳の原因などのことを判断できます。 

1)フローを収集

フローを識別してフローレコードを作成し、キャッシュテーブルに保持します。

フローレコードにはKeyフィールド(フロー識別に使用する情報)があり、このフィール

ドの情報が１つでも異なると別のフローとして識別されレコードが作成される。

もう一つはNon-Keyフィールドで、フローごとに集計されていく。

Keyフィールド

　・　送信元IPアドレス
　・　あて先IPアドレス
　・　TCP/UDPポート送信元番号
　・　TCP/UDPポートあて先番号
　・　L3プロトコル
　・　ToSバイト（DSCP）
　・　入力インターフェース

Non-Keyフィールド

　・　送信元IPアドレス/あて先IPアドレス
　・　送信元ポート番号/あて先ポート番号
　・　入力インターフェースと出力インターフェース
　・　ToSバイト（DSCP）
　・　フローのバイト数、パケット数
　・　送信元AS番号、あて先AS番号

※注意　上記はNetflow v5の場合となり、Netflow v9 の場合KeyフィールドとNon-Keyがかなり増えています。

2)フロー情報のエクスポート

キャッシュサイズは無限ではないので、キャッシュテーブルにに作成されたレコードは定期的に出力される。出力されるタイミングは以下の通り。一回に出力されるフローレコードは最大30レコード。

・ TCPのRSTまたはFINを検出してTCPセッションが終了したとき
・アクティブタイマーが設定時間を経過したとき
・インアクティブタイマーが設定時間を経過したとき
・NetFlowのキャッシュテーブルが一杯になったとき

3)サンプリング

全てのパケット情報を収集することが望ましいが、大規模なネットワークであったり、機器の負荷が気になる場合に、収集する対象や量を制限することができる。

負荷の目安は以下のブログが参考になりそう。

https://designetwork.daichi703n.com/entry/2016/10/08/Performance-of-NetFlow-Cisco

ランダムサンプリング

n個のパケットの連続するパケットの中からランダムに１つを集計する。

例：1/100 とした場合、全パケットの1%が収集。100人が1kbのパケットを送ったとす

　　ると、1人1kbを送った情報しか得られない。

サンプリング数の理論値に関する情報とても参考になります。

https://www.janog.gr.jp/meeting/janog23/doc/d2p5.pdf

Netflow v5 がスタンダードでしたが、最近ではFlexibleNetflow(Netflow v9)が出てきており、対応機種も増えつつあります。v5,v9の違いなんかにも触れつつ、進めていけたらと思います。

今回はここまで。

経験ゼロ AWS ソリューションアーキテクト -アソシエイト- 取得してきました。

皆さんこんにちわ。

これからの時代はクラウドだよ (๑• ̀д•́ )✧+°ﾄﾞﾔ

って周りに言いふらしてましたが、実際にどんなものなのか知りませんでした。

ご・・ごめんなさい(;'∀')

インプリの時のリードタイム削減とか、拡張(柔軟)性、高可用性とか、インフラエンジニアとしては凄くそそられるキーワードが慣れんでいるけども、実際どんなものなのか。

会社でたまたま資格取得の話がありましたのでチャレンジしてきましたので、

その体験記を記します。これから取得される方の役に立てば！

●試験内容

試験費用(15000円)

試験時間130分

全60問で7割以上で合格

試験会場にいって4択の選択式問題をひたすら解きます

●試験勉強

期間：2週間

開始時のクラウド経験値：ゼロ　

試験費用：参考書(2300円)、WEB問題(3500円)

●試験対策

１．参考書

まずは体系的に全体を浅く広くイメージ作りたかったので本読みました。

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書

※経験者曰く、ちょっと内容は濃いらしいです。とりあえず１周しました。

２． ブラックベルト

VPC、EC2、RDS、IAM らへんの主要サービスの動画を見ました。

やっぱり本読むより動画で見たほうがわかりやすい！かなり理解が進みました。

AWS クラウドサービス活用資料集

 ３．WEB問題

過去の問題ではないようなのですが、一問一答形式で回答の解説もついています。

フリーでは20問くらい？しかないですが、有料会員（3900円/月）ですと800問以上の問題にチャレンジ可能です。

AWS WEB問題集で学習しよう

※有料会員で3周くらいやりました。

公式で模擬問題(2000円)というのもありましたがスルーしました。もう問題はお腹いっぱいだったので・・・・

結果。。。。合格ヾ(＠⌒ー⌒＠)ノ

●試験の感想

問題の内容と回答を覚えるだけでは厳しい感じでした。

シナリオ形式の問いが多く、4択ですが回答の内容が結構複雑です。

各サービスの特長や機能イメージをしっかり作ることが大事です！と言ってみますが、

正直WEB問題の回答内容をしっかり理解する(雰囲気ではなくGoogleで事例を調べながら理解)ようにして、3週くらいで嫌でも頭に入ると思います。

●試験を終えてみて

すべてのシステムがクラウドに適してるかというとNOだと思いました。

大規模なWebサービスや、ビックデータ解析とか、アクセス数、データ量が時によってスパイクするようなシステム基盤を作る場合は十分なサービスラインナップかなと思います。

中小規模だと、データ連携の中継とか簡単な開発環境とかになるかなぁ。

S3なんかをうまく利用してファイルサーバみたいなことができたら面白そうです。

マルチテナント向けの自社サービスみたいなものをクラウド基盤で作れれば、もっと深く知れるんだろうなぁ。。

初めての投稿

こんにちわ。

初めての投稿になります。

インフラエンジニアとしてこの方10年。

スモールビジネス～エンタープライズ向けのサーバー運用、保守、構築から始まり、今はネットワークエンジニアに従事しています。

最近は、インフラもクラウドだとか、DevOpsだとか、オンプレが支流のころに比べるとだいぶ様変わりし、求められるスキルセットも複雑になってきました。

最近の技術アップデートについていけない・・・いやいや、年のせいで物忘れ激しいだけだ。本気出せばイケる！

SNSとかブログとは無縁でしたが、備忘録を兼ねてブログをはじめてみようと思いました。

現場で印象に残った出来事や技術的なことを備忘録的にアップしていきます。