30代後半で転職したSEのブログ

転職の経験談、IT技術情報など紹介していきます。

AWS解約

去年のちょうど今頃、AWSの検証用にアカウントを作成しましたが、最近はめっきりAzureを使うようになったので、解約をしてみました。

アカウントの解約 - AWS 請求情報とコスト管理

上記のURLを参考にして、5分で解約できました。

最近、株式口座などどんどん解約しているのですが、どれも紙の書類を郵送したり、なかには3往復ぐらい書類のやりとりをしないと解約できなかったり、またまた、解約用のWebページが見つからず、電話でないと解約できなかったりとすることが多かったのですが、AWSは調査時間あわせても10分で解約できました。

f:id:windows2020:20180524000839p:plain

家に帰るとかゆくなる

最近、仕事が終わり、帰ろうとすると、事務室を出て、エレベーターに入ったあたりから全身かゆくなります。
家に着いた時がピークで、寝ると翌日にはおさまっています。

Google先生に聞いてみると、リラックスした瞬間に疲れやストレスがたまっていると、かゆみが出てくることがあるらしいです。
疲れがたまっているのかもしれませんが、最近は朝4時か5時ぐらいには目が覚めてしまい、長時間寝れていないのが原因かもと考えています。

ペットボトルのキャップ

私が子供のころはペットボトルで販売されている飲料は少なく、ほとんどが缶ジュースでした。
よく、コーラを振って、名札の安全ピンで蓋のところに穴をあけ、噴射させて遊んでました。

ペットボトルが普及しだしたのは1996年ごろらしいです。
500ml以下の飲料にもペットボトルを使えるようになって、普及したようです。
確かこのころは桃の天然水など流行っていた気がします。

ペットボトルが普及してから約20年経つわけですが、ペットボトルのキャップは
20年前と変わらず、そろそろ進化してもいいのではないかと最近思います。
キャップをしっかり閉めることで、こぼれないようにできているのですが、
あけるときには少し時間がかかるので、開けやすくこぼれにくいキャップが開発されると嬉しいです。

希望としては冷蔵庫をあけて、ドリンクをコップに入れて、冷蔵庫を閉めるまでが10秒以内になると
いいなと思います。

リモートデスクトップのプロキシ越え

Azureなどのクラウド環境にWindowsOSを立ち上げると、インターネット経由でリモートデスクトップ接続することになります。会社のネットワークからインターネットにアクセスする場合はプロキシサーバーやファイアウォールを経由する構成になっていることが多く、通常httpやhttps以外のプロトコルはブロックされていると思います。そのため、会社のネットワークからAzure上のWindowsリモートデスクトップでアクセスすることはなかなか難しいです。

結局はプロキシ越えはできなかったのですが、惜しいところまで行けましたので、まとめておこうと思います。

こんな構成だったら成功したはず

RDP over httpsなどでググると解説いただいているページを見かけるかと思います。今回試した方法はRemote Desktop Gateway(以下RD Gateway)を踏み台にして、目的となるサーバにアクセスする方法です。
ネットワーク構成が以下のようなものであれば、アクセスは成功したかと思います。

自分の端末 > ファイアウォール > RD Gateway > ターゲットのサーバ

自分の端末からRD Gateway経由でリモートデスクトップ接続をすると、ファイアウォールhttps(443)のポートで通過するようになります。自分の端末から直接、ターゲットのサーバにリモデでアクセスしようとすると通常はrdp(3389)のポートでアクセスしようとするため、ファイアウォールでブロックされることになります。

こんな構成でもいけるはず

AzureであればAzure Load Balancerを使って以下のような構成もできるはずです。

自分の端末 > ファイアウォール > Azure Load Balancer > ターゲットのサーバ

NAT機能を利用して、Azure Load Balancerがhttps(443)で受け付けて、rdp(3389)に変換するという方式にします。
この構成であれば、RD Gatewayを設定するよりも短時間に設定できます。mstsc上でターゲットのサーバのIPアドレスを指定する際に、IPアドレス:443 と指定すればいけるはずです。

今回NGだった原因

それは、mstscがプロキシ経由で通信してくれなかったからです。
今回試した構成は以下のようなものでした。

自分の端末 > プロキシ > ファイアウォール > RD Gateway > ターゲットのサーバ

mstscがRD Gateway経由でターゲットのサーバにアクセスするように設定はできるのですが、アクセスしようとするとプロキシを経由せずにRD Gatewayにアクセスしようとしてファイアウォールでブロックされてしまいました。
Windows 8の事例ですが、IEのプロキシ設定がmstscのプロキシ設定に反映されるという記事をみかけてやってみたのですが、どうやってもプロキシを経由してくれませんでした。

mstscでプロキシを明示的に設定できると嬉しいのですが。。。

オンプレミスはクラウドより安全なのか

最近、AzureのPaaSサービスの利用を検討しているのですが、どのサービスもインターネットからの
アクセスが許可されています。オンプレ環境を長年構築してきた身としては、社内ネットワーク上のアプリを
インターネットにさらすことになるので、二の足を踏んでしまいます。
そうは言っても、このままだとPaaSで提供されるサービスが利用できないので、今回はオンプレとクラウド
セキュリティ面について書いてみようと思います。

オンプレのセキュリティ

オンプレ上に構築するアプリケーションはインターネットからのアクセスができないということを理由に
セキュリティ対策がおろそかになっていることが多いかと思います。

  • インターネットにアクセスしないから月例のパッチは適用しない
  • サーバ上のAdministratorのパスワードは構築時から変更していない
  • 社内ネットワークに対してはFirewallでの制限を実施していない
  • 社内ネットワークにつながっていれば、リモートデスクトップで接続を試みることができる
  • Firewallで制限しているとはいえ、間接的にはインターネットとつながっている(DMZ経由、クライアント端末経由)
  • マシンルームへは知っている人なら簡単に入れる
  • セキュリティ対策に使える予算は結構少ない
  • など

PaaSのセキュリティ

一方でPaaS(ここではAzure)のセキュリティはというと

  • 国際基準を満たすセキュリティレベル
  • PaaSなので必要最低限のポートしか開いていない
  • セキュリティ対策には各企業が払えないほどの予算をつんでいる(とどこかで聞いた)
  • Azure PortalのIDを取られると何でもできてしまう
  • アプリケーション自体に脆弱性があるとそこからやられてしまう(SQLインジェクションなど)

まとめ

この記事を書き始めたときはPaaSでも意外と安全ですよという落ちにしたかったのですが、
アプリケーション自体の脆弱性を考えるとどちらも一長一短ありでした。

classic asp on webapps

VBSで記述されたいわゆるclassic aspをAzureに移行しようと考えています。
直近問題になっているのはVBS内で親ディレクトリにあるVBSをIncludeして失敗するパターンです。<%@ LANGUAGE=VBScript %>

最近のIISは親ディレクトリの参照をデフォルトでは禁止しており、
オンプレのIISであればapplicationHost.configを書き換えて、
ディレクトリの参照を許可設定する必要があります。

Azure上のWebAppsの場合はapplicationHost.configを追加してもなかなか反映されず、
いろいろ調べているうちに下記のページに行き着きました。

Xdt transform samples · projectkudu/kudu Wiki · GitHub

難しいことはよくわかりませんが、applicationHost.configの代わりにapplicationHost.xdtというファイルを作って、
D:\Home\site配下に設置し、WebAppsを再起動すれば親ディレクトリの参照も可能になりました。

applicationHost.xdtの中身には下記を追記しました。

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <asp xdt:Transform="SetAttributes(enableParentPaths)" enableParentPaths="true" />
  </system.webServer>
</configuration>

ファイルの配置にはKuduを使いました。

これでclassic aspの移行が捗りそうです。

ストレージアカウント 削除 vm起動しない

Azure上のStorageアカウントを使用して、ファイル共有の機能を利用していたのですが、ふと、セキュリティが気になって、削除したところ、IaaSでもそちらのStorageアカウントを使用しており、IaaS上のVMが起動しなくなりました。(正確には起動していているようですが、パブリックのIPが割り当たらない状態でした。)

VMのディスクは管理ディスクで作成しており、Storageアカウントは関係ないと思っていたのですが、Storageアカウントはブート診断時に使用されていました。

復旧方法はVMのブート診断から設定を選び、Storageアカウントを利用可能なものに差し替えて復旧しました。

ブート診断の設定がブートを妨げるという恐ろしい設定でした。